Thanks Shawn. This is very useful. Could you shed some light on how rolled-back transactions (or not-yet-committed transactions for that matter) are treated as far as the binary logs? Are these updates actually go to the binary logs, thus trigger replication to the salve? Thanks, David.
-----Original Message----- From: Shawn Green [mailto:shawn.l.gr...@oracle.com] Sent: Monday, July 30, 2012 11:22 AM To: Zhigang Zhang Cc: mysql@lists.mysql.com Subject: Re: How often the slave to pull data from master? On 7/29/2012 12:52 AM, Zhigang Zhang wrote: > Hi >> If there are additional events beyond that, it > retrieves those in sequence after it writes the current statement into > the relay logs. > > I have a question about this: > > Whether the slave is sent a signal whenever the master generates each event? > Yes, the slave receives a signal but it is not a TCP (networked) signal that the slave receives. Let me add a few more details to the 'retrieval of events from the Binary log' part of the replication process. Each slave that connects to a master will open a 'dump thread' process that keeps track of the end of the binary log. This is a mini-daemon that runs in the context of the overall MySQL server. The slave holds and maintains an open connection with the dump thread and when there are no new events to transmit to the slave, the thread goes to sleep. This does not break the TCP/IP connection to the slave. The 'signal' to the 'slave' is not sent via TCP to the remote server. It is sent to it's proxy, the dump thread, using a pthread_cond_signal event. This wakes the thread and initiates the streaming of new data to the slave. The dump thread is initiated by the slave when it makes its connection. This is considered a 'slave process' as it is the dedicated local listener for the slave process. Each slave gets its own dump thread. When the slave disconnects, the dump thread is destroyed. Using a low-level kernel signal is much more efficient (in terms of network usage and CPU cycles) than to continuously ping one server from the other. This is why we chose this design. For any additional lower-level details than this, I encourage you to review the source as it can tell you much more than most would like to be shared in a general forum like this list. Also, there is a more technical discussion on the internal mechanics of MySQL already in place. The proper place to ask for more details would be the Internals mailing list. -- Shawn Green MySQL Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software, Engineered to Work Together. Office: Blountville, TN -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
