>did u check if any of the file system holding bin-logs/data files are having >enough free space. >If the slave runs out off disk space, then you need to rebuild the slave >from scratch.
Yes lots of free space, so no problem there! >regards >anandkl >On 12/8/08, ewen fortune <ewen.fort...@gmail.com> wrote: > > Hi, > > On Mon, Dec 8, 2008 at 9:20 AM, Marcel Grandemange > <thavi...@thavinci.za.net> wrote: > >>WHat errors are you getting when you try and start the slave? > > > > That's the exact thing.... > > > > mysql> show slave status\G > > *************************** 1. row *************************** > > Slave_IO_State: Waiting for master to send event > > Master_Host: 192.168.11.252 > > Master_User: cjcrepl > > Master_Port: 3306 > > Connect_Retry: 60 > > Master_Log_File: mysql-bin.000005 > > Read_Master_Log_Pos: 98 > > Relay_Log_File: gw2-relay-bin.000099 > > Relay_Log_Pos: 235 > > Relay_Master_Log_File: mysql-bin.000005 > > Slave_IO_Running: Yes > > Slave_SQL_Running: Yes > > Replicate_Do_DB: cjcd0,cjcd0 > > Here you are filtering your replication, are you happy the filter is > correctly applied and that you understand this configuration option. > > Peter from Percona wrote a blog post about this last year. > http://www.mysqlperformanceblog.com/2007/11/07/filtered-mysql-replication/ > > > Replicate_Ignore_DB: > > Replicate_Do_Table: > > Replicate_Ignore_Table: > > Replicate_Wild_Do_Table: > > Replicate_Wild_Ignore_Table: > > Last_Errno: 0 > > Last_Error: > > Skip_Counter: 0 > > Exec_Master_Log_Pos: 98 > > Relay_Log_Space: 235 > > Until_Condition: None > > Until_Log_File: > > Until_Log_Pos: 0 > > Master_SSL_Allowed: No > > Master_SSL_CA_File: > > Master_SSL_CA_Path: > > Master_SSL_Cert: > > Master_SSL_Cipher: > > Master_SSL_Key: > > Seconds_Behind_Master: 0 > > 1 row in set (0.00 sec) > > > > According to the slave all is running and 100%, although the data is > visibly > > outdated. > > And updates to tables or even new tables do not replicate since > connectivity > > loss.. > > This Seconds_Behind_Master: 0 > combined with Slave_IO_Running: Yes and Slave_SQL_Running: Yes > indicate that the slave is both up to date and running without > problems caused by connectivity issues. > > How are you testing the differences between tables? to really know > what is different you need to perform something like a table checksum, > maatkit has a tool for that. > > http://www.maatkit.org/doc/mk-table-checksum.html > > If there really are differences between the two versions of table data > I would suggest you are either filtering replication incorrectly > (remember what filters are for master and which are for slaves) or you > are using non-deterministic functions which when executed on the slave > give a different result, something like this. > > > http://www.mysqlperformanceblog.com/2008/09/29/why-audit-logging-with-trigge rs-in-mysql-is-bad-for-replication/ > > Cheers, > > Ewen > > > > > > > > > > >>What does the error log say? > > > > > > > >> Good Day. > >> > >> Im wondering if someone can assist me. > >> > >> Ive been using replication for a while now and it tends to fail very > >> easily. > >> > >> One of my sites lost connectivity for a while and when it came back > >> obviously replication broke again. > >> > >> How can I get it to populate all data from master again? > >> > >> Load data from master; is being depreciated and doesn't really work > >> anyhow. > >> I do not wish to create dump and do this manually every time it fails. > >> > >> > >> Advise? > >> > >> Also is replication really this unreliable? It breaks at the slightest > >> hiccup... > >> > >> > >> -- > >> MySQL General Mailing List > >> For list archives: http://lists.mysql.com/mysql > >> To unsubscribe: > >> http://lists.mysql.com/mysql?unsub=john.dais...@butterflysystems.co.uk > >> > >> > >> ______________________________________________ > >> This email has been scanned by Netintelligence > >> http://www.netintelligence.com/email > >> > >> > > > > > > -- > > MySQL General Mailing List > > For list archives: http://lists.mysql.com/mysql > > To unsubscribe: > http://lists.mysql.com/mysql?unsub=ewen.fort...@gmail.com > > > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql?unsub=anan...@gmail.com > > __________ NOD32 3670 (20081208) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org