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?
From: Shawn Green [mailto:shawn.l.green@stripped]
Sent: Monday, July 30, 2012 11:22 AM
To: Zhigang Zhang
Subject: Re: How often the slave to pull data from master?
On 7/29/2012 12:52 AM, Zhigang Zhang wrote:
>> 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 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.
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.