Step Two: Configure The Slave.
Go ahead and stop the MySQL server on the slave, and move the database directories you copied above to
the data directory on the slave server. Be sure to change the ownership and group of the directories
recursively to the MySQL user, and change the file mode to 660 (read-write for owner and group only) on
the files, and the directories themselves to 770 (read-write-execute for owner and group only).
the data directory on the slave server. Be sure to change the ownership and group of the directories
recursively to the MySQL user, and change the file mode to 660 (read-write for owner and group only) on
the files, and the directories themselves to 770 (read-write-execute for owner and group only).
Now go ahead and start the MySQL server on the slave to ensure everything is working fine. Run a few select
queries (no updates or inserts) to make sure the data snapshot you took in step one was successful. Go ahead
and shutdown the server after successful testing.
queries (no updates or inserts) to make sure the data snapshot you took in step one was successful. Go ahead
and shutdown the server after successful testing.
The slave needs to be configured to look to a specific master to receive its updates, so we need to edit the
‘my.cnf’ file on the slave, adding the following lines to the[mysqld]portion.
‘my.cnf’ file on the slave, adding the following lines to the[mysqld]portion.
master-host=10.1.1.1 master-user=replicate master-password=password
After starting the slave server, it will automatically look the master specified in the ‘my.cnf’ file for any
updates and incorporate those changes into its databases. The slave server keeps track of what updates it has
received from its master in the ‘master.info’ file. The status of the slave thread can be seen through the sql
command ‘SHOW SLAVE STATUS’. Any errors in processing the binary logs on the slave will cause the slave thread
to exit, and generate a message in the *.err log. The errors can then be corrected, and the sql statement
‘SLAVE START’ can be used to restart the slave thread, where it will pick up where it left off in the binary
log of the master.
updates and incorporate those changes into its databases. The slave server keeps track of what updates it has
received from its master in the ‘master.info’ file. The status of the slave thread can be seen through the sql
command ‘SHOW SLAVE STATUS’. Any errors in processing the binary logs on the slave will cause the slave thread
to exit, and generate a message in the *.err log. The errors can then be corrected, and the sql statement
‘SLAVE START’ can be used to restart the slave thread, where it will pick up where it left off in the binary
log of the master.
By now the changes made to the data on the master should have replicated to the slave, and you can
test this by inserting or updating a record on the master, and then selecting it on the slave.
test this by inserting or updating a record on the master, and then selecting it on the slave.
Now we have a master -> slave relationship from A -> B, which would allow us to redirect all of our queries to
B if A should be down, but we have no way of getting any updates to the databases back to A when it is brought
back up. To solve that problem, we create a master -> slave relationship from B -> A.
B if A should be down, but we have no way of getting any updates to the databases back to A when it is brought
back up. To solve that problem, we create a master -> slave relationship from B -> A.
