> We have a PSE05 "Master" and PSE06 "Slave" (PRODUCTION servers) both > are > Ubuntu 32-bit. > We have a third slave PSE07 which is Ubuntu 64-bit. This is our 'live > backup' so to speak. We take mysqld down daily on there and tarball the > /var/lib/mysql and /var/log/mysql as snapshots (since mysqldump would > take > a week literally to re-import). > Our data is about 100GB and nearly 1 Billion records and growing by > several > hundred thousand per day.
A medium sized installation, but still too big to do a quick dump-n-restore that the mysql docs always suggest. > We had some replication hose-up where someone accidentally wrote to the > PSE06 slave. This wasn't caught right away and so it cascaded and > queued up > about 130 rows to be written. Obviously going through this whole > business: > > mysql> stop slave; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start slave; > show > slave status\G > > Would take WAY too long and painful. Painful for 130 rows? Script it ... check "show slave status", and if replication is off execute "SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start slave;" > So is this even possible. Are the ibdata files binary compatible > between > "bit" versions (or even different OS's for that matter) Its safe, but this is not the way to fix your problem. You should use Maatkit mk-table-checksum and mk-table-sync: http://www.maatkit.org/doc/mk-table-checksum.html http://www.maatkit.org/doc/mk-table-sync.html > We are getting errors: > > 101013 23:56:22 [Warning] Neither --relay-log nor --relay-log-index > were > used; so replication may break when this MySQL server acts as a slave > and > has his hostname changed!! Please use '--relay-log=mysqld-relay-bin' to > avoid this problem.^M Probably you didn't set "log-bin" in my.cnf with a value? HTH, ds -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
