On 01/13/2011 05:34 PM, Larry H. wrote:
So just to clarify I would be rsyncing the contents of the dbmail database
folder (/var/lib/mysql/dbmail) to the slave.
No, you'll need to get all of /var/lib/mysql, because that's where the
innodb write-ahead logs are which also must be in sync.
Then stopping the master and
rsyncing the innodb log files in (/var/lib/mysql) to the slave. Also, won't
rsync miss some of the new data coming in on the master as it completes
certain tables in the data directory during the rsync or is that what the
second pass is for?
That's why you do the second rsync pass with the master DB off.
The reason to do it 2-pass is to minimize the downtime in the 2nd pass
since most of the data won't need to be changed again.
Gordan
Gordan Bobic wrote:
Larry H. wrote:
I haven't gone as far as doing a full dump and restore just yet.
That's probably a good place to start. You absolutely have to make sure
beyond any doubt that the data is in sync. That means preventing all the
writes to the master DB while you are dumping.
One trick you could use is double-rsync.
- Stop the slave database
- rsync data to the slave while the master is running.
- Stop the master database (yes, this unavoidably means downtime)
- rsync the entire master DB subtree (innodb log files and all the table
files) - this should take less time synce the first pass should have,
hopefully, caught most of it.
- Purge the binlogs on both sides, and the binlog index files
- Stop any services from accessing the DBs
- Start the DBs, re-instant replication from log 0 position 0.
- Start any services accessing the DBs.
Then they should be in sync. Any kind of online sync is not going to
achieve this.
The imap,pop
and lmtp services are not running on the secondary master so I don't
think
they are being accessed. Smtp is running on the secondary master but I
have
postfix configured to relay lmtp to the primary master which the logs
tell
me it's doing. When the replication does break I run the following
command
and the replication seems to catch up.
STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
Does this not necessarily mean that my databases are in sync?
Absolutely not. All you are doing there is skipping the query that
caused a problem and continuing. You aren't actually fixing the root
cause.
Also what do you use for packet logging?
iptables -j LOG is a good place to start.
Gordan
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
