I'm only a digest subscriber, so I apologise in advance for any mis-quotes: Ok here is my experience with MySQL replication: 1) it's been very stable, and haven't noticed any drift in the replicating servers 2) we have ~7 replicating servers-- 3 in circular replication which recieve all of the updates 4 hanging off various other servers, which are not used for main updates (primarially read-only replication for these slaves.) 3) we're using a combination of MySQL 3.23.36 and 3.23.38 4) our servers are in vastly different geographic locations for redundancy, convienience and speed 5) replication occasionally hangs for > 20 minutes due to slow network connections -- seems to remain hung after all of the congestion goes away though...There are a couple of enhancements that I'd suggest for the documentation: 1) Indicate/make more obvious that SELECT prigilege is needed for the replication user on the master server if the 'LOAD TABLE tablename FROM MASTER' syntax is used. The GRANT FILE ... is only useful if there is _only_ replication going on for that user. 2) I'm not completely sure, but I would assume that there is no need to grab the binary logs or master.info from the master server. (grabbing the master.info file _might_ cause grief to the slaved servers... I dunno) 3) don't attempt doing a 'create database databasename' when not USEing a database that's replicating, as the create database command does not propagate (Think it might be considered a bug, but might also be considered a maintenence issue) 4) warn that DROP TABLE happens very quickly and very resoundingly on all replicating servers ;-) ditto for changing access permissions... As for specific problems: > 010410 16:37:24 Slave: Failed reading log event, reconnecting to > retry, log 'FIRST' position 4 > 010410 16:37:24 Slave: reconnected to master > '[EMAIL PROTECTED]:3306',replication resumed in log 'FIRST' at > position 4 > 010410 16:37:24 Error reading packet from server: Binlog has bad > magic number, fire your magician (read_errno 0,server_errno=65535) > > and in the master log: > > 010410 16:35:58 3006 Connect [EMAIL PROTECTED] on > 3007 Connect [EMAIL PROTECTED] on > 3007 Quit > 3006 Binlog Dum > > What is wrong? Where do I get a better magician? It appears that the binary log(s) on your master machine is/are corrupt... Don't know exactly why this might have happened as I've never ran into it. You might want to consider stopping the master server, wipe all of the binary logs on the master (/var/lib/mysql/*-bin.*) wipe the master.info file on the slaved machine get your snapshot of data onto your slave machine again as per the docs restart the master server... Hope this helps Scott V PS I know how people feel when there are no responses to their questions, but hey, it's possible to buy support contracts ;-) The list is free so deal with the support you can get ;-) For what it's worth, here's the replication setup on one of the master/slave machines(hosts,users and passwords have been changed to protect the innocent): ---------------------- [mysqld] server-id=10 log-bin log-slave master-host=server master-user=repl master-password=X123 binlog-ignore-db=scratch set-variable = net_read_timeout=120 set-variable = net_write_timeout=240 set-variable = max_binlog_size=134217728 --------------------- The timeouts are there because of the lag involved in the WAN connections that we're replicating across. The user 'repl' is on 'server' with FILE,SELECT, and PROCESS privileges (I thought that they needed PROCESS at one time in the docs, but I don't see them there anymore...) Permissions granted as so... GRANT FILE,SELECT,PROCESS ON *.* TO repl@'%' IDENTIFIED BY 'X123'; Just in case for the filter(sql database) --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
