> We have a PSE05 "Master" and PSE06 "Slave" (PRODUCTION servers) both
> 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
> a week literally to re-import).
> Our data is about 100GB and nearly 1 Billion records and growing by
> 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
> mysql> stop slave; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start slave;
> 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
> "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:
> We are getting errors:
> 101013 23:56:22 [Warning] Neither --relay-log nor --relay-log-index
> used; so replication may break when this MySQL server acts as a slave
> 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?