MySQL currently in application does not adopt the dual-machine hot backup strategy. However, considering the high availability of the system, dual-machine hot backup is necessary. In addition, after implementing data hot backup, It can further realize the separation of reading and writing, and improve the performance of accessing data in applications. Why not do it? Currently, I have a few idle machines, so I started to do it.
Machine A: (10.0.9.199), Machine B: (10.0.9.1)
Because it is a two-way hot backup, first set the One database (db1) is the master, and the backup database (db2) on B is the slave. This is one direction; then configure db2 as the master and db1 as the slave
log-bin=mysql-0-bin #设定生成log文件名 #机器A配置 server-id=9199 # 主ID,与从ID不能相同 binlog-do-db=webgps4_0 #设置同步数据库名 binlog-ignore-db=mysql #避免同步mysql用户配置 replicate-do-db=webgps4_0 // 两处webgps4_0是一致的 replicate-ignore-db=mysql
log-bin=mysql-1-bin #设定生成log文件名 #以下为机器B配置 server-id=9001 # 主ID,与从ID不能相同 binlog-do-db=webgps4_0 #设置同步数据库名 binlog-ignore-db=mysql #避免同步mysql用户配置 replicate-do-db=webgps4_0 // 两处webgps4_0是一致的 replicate-ignore-db=mysql
CREATE USER 'test'@'10.0.9.1' IDENTIFIED BY '123456'; //test为账号,10.0.9.1表示账号只能从指定id也就是B机器访问,最后123456是密码,机器A上执行 CREATE USER 'test'@'10.0.9.199' IDENTIFIED BY '123456'; //机器B上执行
grant replication slave,reload,create user, super on *.* to 'test'@'10.0.9.1' IDENTIFIED BY '123456'; // 机器A上执行 grant replication slave,reload,create user, super on *.* to 'test'@'10.0.9.199' IDENTIFIED BY '123456'; // 机器B上执行
mysql> change master to -> master_host = '10.0.9.1', -> master_port = 3306, -> master_user = 'test', -> master_password = '123456'; //机器A上执行,A为slave mysql> change master to -> master_host = '10.0.9.199', -> master_port = 3306, -> master_user = 'test', -> master_password = '123456'; //机器B上执行,B为slave
Because it is a two-way backup, many operations in the configuration are The only difference is that the order of master and slave is inconsistent, one is forward and the other is reverse. Bidirectional backup has been implemented here. Now you can do some operations in the two libraries to see the effect.
Currently, only db1 and its backup bidirectional master-slave are configured, which means that only one schema is guaranteed to be hot standby. In actual applications, multiple schemas are often used to reduce the pressure on a single server, such as the schema of machine A in this article. The backup is on B, and the backup of B is on C. Some backups are configured in a ring. It should be noted that when configuring hot standby on machine B, configuring master or slave cannot be performed in the previous database instance. Repeated configuration on the same port number will overwrite the previous one. Therefore, you need to use mysqld_multi to start multiple instances on a single machine. mysql instance, configuration is done in another mysql instance. For the configuration of mysqld_multi, check the blog post: MySQL - Starting multiple MySQL instances on a single machine in Linux (mysqld_multi
)
The main library must enable Bin log, and the main library and slave library must have unique Server Id
The slave library must clearly know which offset position of which Bin log file in the main library to start copying from.
The slave library can only copy from the main library The specified database, or some data tables of the database
The database names of the master database and the slave database can be different, but it is still recommended to use the same name
The MySQL versions of the master database and the slave database must be consistent
From MySQL3.23.15 onwards, MySQL supports one-way asynchronous replication. In other words, one MySQL server acts as the Master (main database), one or more MySQL servers act as Slaves (slave databases), and data is replicated asynchronously from the Master to the Slaves. Note that this replication is asynchronous and different from MySQL's synchronous replication implementation (this implementation is called MySQL Cluster).
When the main library is updated, the main library will write the SQL of the update operation into the binary log (Bin log), and maintain an index of the binary log file to facilitate log file rotation (Rotate). When the slave library starts asynchronous replication, the slave library will start two I/O threads, one of which connects to the main library, requiring the main library to transfer the changes in the binary log to the slave library, and write the returned log locally. disk. Another thread is responsible for reading the locally written binary log and executing it locally to reflect this change. The older version only enabled one I/O thread during copying to implement these two parts of the function.
The above is the detailed content of MySQL-sample code for dual-machine bidirectional hot backup. For more information, please follow other related articles on the PHP Chinese website!