The MySQL master-slave synchronization architecture is one of the most used database architectures. The MySam engine is responsible for adding, modifying, and deleting operations, and the InnoDB engine is responsible for querying, so-called read-write separation. Especially for websites with heavy load, the management of master-slave synchronization is also very important. Novices often do not know how to start when master-slave synchronization errors occur. This article is based on my own experience. Describe the mysql master-slave in detail management.
The role of MYSQL master-slave synchronization
(1) data distribution
(2) load balancing
(3) backup
(4) high availability and fault tolerance
The principle of MYSQL master-slave synchronization
Regarding the master-slave synchronization of MYSQL, the most important thing is to understand how the master-slave synchronization of MYSQL works, that is, the principle of master-slave synchronization. The following figure can clearly guide the process of its work:
Briefly describe the process: the IO thread of the slave server obtains the binary log from the master server and saves it as a relay log locally, and then executes the contents of the relay log on the slave through the SQL thread, so that the slave library and the master library keep Consistent. The detailed process of master-slave synchronization is as follows:
1. The master server verifies the connection.
2. The master server starts a thread for the slave server.
3. The slave server tells the master server the offset bit of the master server log.
4. The master server checks whether the value is less than the current binary log offset bits.
5. If it is less than, notify the slave server to fetch data.
6. The slave server continues to fetch data from the master server until it is finished. At this time, the slave server thread goes to sleep, and the master server thread goes to sleep at the same time.
7. When the master server has an update, the master server thread is activated, pushes the binary log to the slave server, and notifies the slave server thread to enter the working state.
8. Execute the binary log from the server SQL thread and then go to sleep.
MYSQL master-slave synchronization construction actual combat
The construction of master-slave synchronization is a relatively delicate technical task. Doing some things well in the early stage will make you reduce a lot of work in the future work. You need to pay attention to some problems when building. Problems that need to be paid attention to, so that beginners can effectively avoid some potential problems at the beginning (MYSQL installation is not introduced here):
1. Introduction to the master-slave synchronization environment
Operating system environment: Centos 5.5 64 bit
MYSQL version: MYSQL 5.1.50
IP of the main server: 10.1.1.75
IP of slave server: 10.1.1.76
2. Create a synchronization account on the main server
GRANT REPLICATION SLAVE,FILE ON *.* TO 'replication'@'10.1.1.%' IDENTIFIED BY '123456';
FLUSH PRIVILEGES;
Note: Don't make the password too simple when setting permissions!
3. Changes from the server configuration file
server-id = 2
replicate-wild-ignore-table=mysql.%
log-slave-updates #This can be turned on if necessary
Notice:
1) The server-id item needs to be carefully checked, and must not conflict with the main server, otherwise there will be inexplicable problems, because the server-id will be judged when synchronizing, if the server-id is the same No synchronization is performed, otherwise it may cause an infinite loop ( when the main master is synchronized or the ring is synchronized ) .
2) Some people will wonder why I use the replicate-wild-ignore-table parameter here instead of replicate-do-db or replicate-ignore-db to filter the databases that need to be synchronized and the databases that don't need to be synchronized. Here are a few reasons:
A. The replicate-wild-ignore-table parameter can synchronize all updates across databases, such as replicate-do-db or replicate-ignore-db will not synchronize similar
use mysql;
UPDATE test.aaa SET amount=amount+10;
B. replicate-wild-ignore-table=mysql.% can be easily added when the synchronization database needs to be added in the future without restarting the database of the slave server. Because it is likely that other databases will need to be synchronized in the future.
3) auto_increment_increment and auto_increment_offset parameters, these two parameters are generally used in main-main synchronization to stagger self-increment and prevent key-value conflicts .
4) --slave-skip-errors parameter, don't use these parameters to skip errors unless you are very sure what you are doing. When you use these parameters, MYSQL will ignore those errors, which will lead to inconsistent data between your master and slave servers.
4. Get a snapshot version from the master server
If you have MYISAM or both MYISAM and INNODB export a snapshot of the server using the following command on the master server:
mysqldump -uroot -p --lock-tables --events --triggers --routines --flush-logs --master-data=2 --databases test > db.sql
If you tried only INNODB, use the following command:
mysqldump -uroot -p --single-transaction --events --triggers --routines --flush-logs --master-data=2 --databases test > db.sql
Here you need to pay attention to the use of several parameters:
--single-transaction This parameter only applies to innodb.
--databases is followed by the library names of all other databases except mysql. I only have one test library here.
The --master-data parameter will record the location of the mysql binary log when exporting the snapshot, which will be used later.
5. Restore the snapshot version to the slave server
mysqldump -uroot -p -h 10.1.1.76 test < db.sql
After the snapshot version is restored to the slave server, the data on the slave server is consistent with the data on the master server.
6. Use the change master on the slave server to synchronize from the master server
Use the grep command to find the name and location of the binary log
[root@ns1 ~]# grep -i "change master" db.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=106;
Generate a CHANGE MASTER statement and execute it on
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='10.1.1.75',MASTER_USER='replication',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=106;
START SLAVE;
This completes the construction of master-slave synchronization, and finally use SHOW SLAVE STATUS\G; check the status of Slave_IO_Running and Slave_SQL_Running, if both are Yes, you're done.
Note : Do not write synchronized information into the configuration file, which is inconvenient to manage, especially if there are changes that require restarting.
MYSQL master-slave synchronization management
Here are some commands to manage MYSQL master-slave synchronization:
1. Stop MYSQL synchronization
STOP SLAVE IO_THREAD; #Stop the IO process
STOP SLAVE SQL_THREAD; #Stop the SQL process
STOP SLAVE; #Stop IO and SQL processes
2. Start MYSQL synchronization
START SLAVE IO_THREAD; #Start IO process
START SLAVE SQL_THREAD; #Start the SQL process
START SLAVE; #Start IO and SQL process
3. Reset MYSQL synchronization
RESET SLAVE;
Used to make the slave forget its replication position in the master's binary log, it deletes the master.info and relay-log.info files, as well as all relay logs, and starts a new relay log, when you This operation can be performed on the slave when the master and slave are not required. Otherwise, it will be synchronized in the future, which may overwrite your database. I have encountered such silly things before. Ha ha!
4. View MYSQL synchronization status
SHOW SLAVE STATUS;
This command mainly checks the values of Slave_IO_Running, Slave_SQL_Running, Seconds_Behind_Master, Last_IO_Error, Last_SQL_Error to grasp the status of replication.
5. Temporarily skip MYSQL synchronization errors
When my friend mysql master-slave synchronization encounters errors, such as a primary key conflict, etc., then I need to temporarily skip this error while ensuring that the row of data is consistent, then I need to use the SQL_SLAVE_SKIP_COUNTER = n command, n is to skip the next n events. For example, I skip an event as follows:
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
6. Resync from the specified location
Sometimes after there is a problem with the master-slave synchronization, you need to synchronize from the next position of the log position, which is equivalent to skipping the error. At this time, you can also use the CHANGE MASTER command to deal with it, as long as you find the corresponding log position, for example :
CHANGE MASTER TO MASTER_HOST='10.1.1.75',MASTER_USER='replication',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=106;
START SLAVE;
Introduction to the management experience of MYSQL master-slave synchronization
1. Do not use the SQL_SLAVE_SKIP_COUNTER command indiscriminately.
After this command is skipped, it is very likely that your master-slave data will be inconsistent. Be sure to record the specified errors first, and then check whether the data is consistent, especially the core business data.
2. Combine with the percona-toolkit tool pt-table-checksum to regularly check whether the data is consistent.
This is something that DBAs must do on a regular basis, huh, why not do it if you have the right tools? In addition, percona-toolkit also provides a solution to database inconsistency, you can use pt-table-sync, this tool will not change the main data. You can also use pt-heartbeat to see the replication lag from the slave. For details, please check: http://blog.chinaunix.net/uid-20639775-id-3229211.html .
3. Use the replicate-wild-ignore-table option instead of replicate-do-db or replicate-ignore-db .
The reason has been explained above.
4. Adjust the log mode of the master server to mixed .
5. Each table is added with a primary key. The primary key will affect the synchronization of the database, especially in the R OW replication mode.
http://blog.csdn.net/gaowenhui2008/article/details/46698321