OurDelta

Strange behavior with mirror-bin log patch

Asked by AdmobDB

We downloaded and start using the mirror bin-log patches, but the behavior is strange. Both master and slave have same version i.e. 5.0.67-d7-ourdelta44 and necessary settings for mirror bin-logs. I am trying to setup new slave from this master db server. When I start replication on slave it creates the identical bin-log file to the one on master. I have 2 questions,

1] I was under impression before starting the replication it will download all the prior bin-log files to slave, but that does not happen. It just download the recent one i.e one specified in "change master " command.
2] If I stop replication for backup or business needs like keeping slave few hours behind, the bin-log file on slave gets all the events from master starting from beginning. It does not take into account that the replication is merely resuming and do not need all the events right from beginning. Otherway if it has to do then it should overwrite and not append.

Does anyone experienced similar behavior ? Or please comment on suggested use.

Question information

Language:
English Edit question
Status:
Answered
For:
OurDelta Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Mark Callaghan (mdcallag) said : 		#1

It has been a long time since I used mirror binlog. Percona is the current expert on this. I think that the behavior for 1) might be what was implemented. Can you elaborate on 2)? The mirror binlog code runs when the IO thread in the slave is running. If you start/stop the IO thread it should resume mirroring the binlog from where it left off. How do you stop replication?

Revision history for this message
AdmobDB (bhushan-admob) said : 		#2

Thanks Mark for responding my question.
 I stop the replication by using "stop slave" command. And restart the replication using "start slave" command. Here are the log entries from "error-log" on slave db server,
===================
090128 0:46:11 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000005' at position 98, relay log '
./mysqld-relay-bin.000001' position: 98
090128 0:46:11 [Note] Slave I/O thread: connected to master '<email address hidden>:3306', replication started in log 'mysq
l-bin.000005' at position 98
090128 0:46:11 [Note] ReplicationMule: MULE_BEHIND - new(4), old(98)
090128 0:46:11 [Note] ReplMule::dumpEvent - new status(1) master_log_pos(4), dump_pos(98), file_size(4)
090128 0:46:11 [Note] ReplMule::dumpEvent - new status(2) master_log_pos(98), dump_pos(98), file_size(4)
090128 0:53:36 [Note] Slave: received end packet from server, apparent master shutdown:
090128 0:53:36 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000005' position 98
090128 0:53:36 [ERROR] Slave I/O thread: error reconnecting to master '<email address hidden>:3306': Error: 'Lost connection
 to MySQL server at 'reading initial communication packet', system error: 111' errno: 2013 retry-time: 60 retries: 86400
090128 0:54:05 [Note] Slave I/O thread killed during or after a reconnect done to recover from failed read
090128 0:54:05 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000005', position 98
090128 0:54:05 [Note] Error reading relay log event: slave SQL thread was killed
090128 0:54:08 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000005' at position 98, relay log '
./mysqld-relay-bin.000001' position: 98
090128 0:54:08 [Note] Slave I/O thread: connected to master '<email address hidden>:3306', replication started in log 'mysq
l-bin.000005' at position 98
090128 0:54:08 [Note] ReplicationMule: MULE_BEHIND - new(4), old(98)
090128 0:54:08 [Note] ReplMule::dumpEvent - new status(1) master_log_pos(4), dump_pos(98), file_size(4)
090128 0:54:08 [Note] ReplMule::dumpEvent - new status(2) master_log_pos(98), dump_pos(98), file_size(4)
090128 1:25:11 [Note] Slave I/O thread killed while reading event
090128 1:25:11 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000006', position 654415
090128 1:25:11 [Note] Error reading relay log event: slave SQL thread was killed
090128 1:25:14 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000006' at position 654415, relay l
og './mysqld-relay-bin.000002' position: 654552
090128 1:25:14 [Note] Slave I/O thread: connected to master '<email address hidden>:3306', replication started in log 'mysq
l-bin.000006' at position 654415
090128 1:25:14 [Note] ReplicationMule: MULE_BEHIND - new(4), old(654415)
090128 1:25:14 [Note] ReplMule::dumpEvent - new status(1) master_log_pos(4), dump_pos(654415), file_size(4)
090128 1:25:15 [Note] ReplMule::dumpEvent - new status(2) master_log_pos(654415), dump_

=======

Also on the slave following commands are disabled,

reset master;

While following command returns error when relication is stopped, i.e stop slave,
show binary logs;

Let me know if you have question/needs additional details from our side.

Thank you,

Revision history for this message
Mark Callaghan (mdcallag) said : 		#3

I am sorry. I don't know what the mirror binlog log messages mean. We don't use this anymore and it wasn't in the latest Google patch. Your only hope is Percona as that is where OurDelta got this patch.

Can you help with this problem?

Provide an answer of your own, or ask AdmobDB for more information if necessary.

To post a message you must log in.