Except that changes made on the master are not automatically picked up by the slaves.
My bad, I wasn't running "START SLAVE" to get them going. Seems odd that this has to be done manually.
Also, overnight, my slaves reported this error:
041108 19:06:42 [Note] Slave I/O thread: connected to master '[EMAIL PROTECTED]:3306', replication started in log 'masterdb-bin.000003' at position 7803960
041108 19:06:42 [ERROR] While trying to obtain the list of slaves from the master 'masterdb.org:3306', user 'repl_user' got the following error: 'Access denied; you need the REPLICATION SLAVE privilege for this operation'
041108 19:06:42 [ERROR] Slave I/O thread exiting, read up to log 'masterdb-bin.000003', position 7803960
... which means my slaves weren't working all night long. Grr.
So I've reset my permissions (as per user comments on the mysql.com documentation pages for the HOWTO) to the following:
use mysql
DELETE FROM user WHERE User='repl_user'
GRANT SELECT, PROCESS, FILE, SUPER, REPLICATION CLIENT, REPLICATION SLAVE, RELOAD ON *.* TO 'repl_user'@'slave1' IDENTIFIED BY 'repl_passwd';
GRANT SELECT, PROCESS, FILE, SUPER, REPLICATION CLIENT, REPLICATION SLAVE, RELOAD ON *.* TO 'repl_user'@'slave1' IDENTIFIED BY 'repl_passwd';
FLUSH PRIVILEGES
If a slave dies, is there any way to determine that state from an external point of view (ie: via Perl/DBD) so we can write a script of some kind to either connect to the slave and issue a "START SLAVE" or send the last xx lines of the .err log file to our tech staff?
-id
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
