Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to understand the DUMP thread of the main library". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "how to understand the DUMP thread of the main library"!

The DUMP thread starts the function call process

1. Multiple select interactions. The slave library needs to save the information of the master library.

2. Register the slave database information

3. Read all kinds of information sent from the library

The information com_binlog_dump_gtid reads from the library includes-server id-the name of the binlog to be read-the bit read-from the library GTID-kill_zombie_dump_threads kills the DUMP thread before the slave library, based on the joint judgment of UUID and SERVER_ID-mysql_binlog_send-Binlog_sender sender saves the read information-sender.run ()-Binlog _ sender::init initialization detection-connection error "Binary log is not open" is not allowed if the main library binlog is not on-if master server id is 0, the connection error "Misconfigured master-master server_id is 0" is not allowed-if the GITD_MODE master library under the GITD protocol must be ON Otherwise, the error The replication sender thread cannot start in "" AUTO_POSITION mode: this server has GTID_MODE =%. 192 s "" instead of ON. -Binlog_sender::check_start_file () to determine whether the GTID value of the slave library is feasible, and to open the file that is to confirm the binary log file-take out the slave library that the GTID of the master library server_uuid is less than or equal to the GTID of the master library. If not, it simply says that the slave library has more things than the master library. For example, the main library 1:1-20 2:1-10 slave library: 1:1-15 2:1-30 to determine whether 1-15 is less than or equal to 1-20 Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog! = 1. The master may or may not have rolled back transactions that were already replicated to the slave. Suggest to replicate any transactions that master has rolled back from slave to master, and/or commit empty transactions on master to account for transactions that have been committed on master but are not included in GTID_EXECUTED. "- determine whether the GTID_PURGED of the master library of the master library is a subset of the GTID of the slave library. Either an error is reported or the master library has cleaned up the GTID needed to pull from the library. For example, the master library GTID_PURGED:1:1-10 2:1-5 slave 1:1-10 because the slave library still needs 2:1-5 these GTID master libraries have no error The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires. -there is also a special case in the above case, such as the manual deletion of binary logfile by the main library. In this case, GTID_PURGED may not have updates that need to be checked. This step involves the actual binlog scan. First scan the last binlog to get the P_EVENT to check whether the GTID you need to pull is after that. It is over, otherwise check the last binlog file to pull the same P_EVENT to check whether the GTID to be pulled is after that, if the delay is high and the relay log reocvery parameter is set, the process may be a little long, such as tens of seconds. The way to determine is to pull the P_EVENT to determine whether it is a subset of the required GTID, which is normally a quick step. If you don't find it in the end, you will also report an error. In the past, a friend asked me if I could omit this step. The reason why I know that this step cannot be omitted is that the GTID_PURGED mentioned above may not be allowed. And later, you need to open this binlog as the starting point of the scan binlog The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires. -save files to LOG_INFO m_linfo Test in the open this binlog file into the loop will continue to read the next file, if not the history binary log is the current file binary log will be blocked in the send_binlog will continue to read, this layer loop is a circular binary log file a file If it is not historical binary log, of course binary log will block-open_binlog_file opens the file initialization read cache IO_CACHE initialization CACHE to read the CACHE size 8K file points to the corresponding binary log-Binlog_sender::send_binlog-read from the initialization point-get_binlog_end_pos gets the last bit of the binary log If it is the current binary log, block the acquisition and send the heartbeat EVENT to get the current read position and enter the loop to get the last point of the current bianry log-if it is not the current binary log to get the last position of the binary log that needs to be read if (log_pos = = end_pos) Read to the end of the file and return 0 otherwise return the last position-if the current binary log wait_new_events (log_pos) waits for the arrival of the new event to enter the state sending all event-wait_with_heartbeat the main logic is through & update_cond & LOCK_binlog_end_pos to complete the description of the loop waiting for the heartbeat m_heartbeat_period if there is no new event and then send a heartbeat event to the slave library to carry the current binlog location. If you are interested in break exiting the return 1 pthread_cond_timedwait implementation, take a look at the implementation here. The main reason is that the function is awakened by the signal and returns 0 if the timeout is etimeout. -send_events sends the binlog of the corresponding location to the binlog event from the library while loop to read the corresponding location-get the TYPE of the EVENT-check-if the auto_position=ON cannot have an anonymous event, if there is an error Cannot replicate anonymous transaction when AUTO_POSITION = 1, at file% .512s, position% lld. -if GTID_MODE=ON cannot have anonymous event, otherwise error Cannot replicate anonymous transaction when @ @ GLOBAL.GTID_MODE = ON, at file% .512s, position% lld-if GITD_MODE=OFF cannot have GTID's event, Cannot replicate GTID-transaction when @ @ GLOBAL.GTID_MODE = OFF, at file% .512s, position% lld will not actually occur in normal operation. Because each time you set GITD_MODE, you always switch one binlog, but these errors may occur if you modify the GTID_MODE and do not follow the previously mentioned process. The first error is easy to reproduce because the auto_postion is passed in by start slave initialization. For the second and third errors, because the generating thread of EVENT and the DUMP thread are not the same thread, it is the way to notify asynchronously, that is, these problems may occur if the GTID_MODE is modified during the time between the generation of GTID event and sending. -it's just that the file name,POS is transferred from the master info of the slave library. In this case, the GTID that has been executed by the slave library will be filtered out, so the master database will filter again in GTID mode. It's safer. -send event here. I believe you have a better understanding of "how to understand the DUMP thread of the main library". You might as well do it in practice! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.