![]() ![]() You’ll see something like this: +-+-+-+-+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +-+-+-+-+ | mysql - bin. Let’s see where the master’s last log entry was: mysql # show master status ![]() Notice that MySQL still works fine and all writes are committed to memory – so there’s no downtime. Thanks to the above command, database writes cannot be committed to disk for now. Just so that we’re on the same page here: you now have TWO SSH sessions open, one still connected to your physical server’s OS, and another which shows your MySQL prompt. To do this, login to MySQL from a different session and issue the following command: mysql # flush tables with read lock We also need to make sure nobody is writing anything to the master while we look at this. Getting the Master Coordinatesīefore we continue, we need to know where the master’s last statement was written in the log. If they’re already commented out or not even present – even better. Add a # (hash) in front of each line to do this. These need to be deleted or commented out for replication to work properly. Note that you may find the following statements in your configuration file: skip - networking You can also check which file is currently being used by checking mysql-bin.index which contains a list of all log files that have been used over time. Hence it’s worth cleaning out those logs from time to time. MySQL will write these files in sizes of up to 1GB, then start the next one. To check that your server is logging things, head over to /var/ lib / mysqlĪnd see if a file by the name of mysql-bin.000001 has been created. Save your file and restart MySQL using service mysqld restart We need to add the following statements to give our master an ID and setup logging: Login to your Master Server as root and edit the MySQL configuration file called /etc/my.cnf. Therefore the slave just remembers the position of where he last read the log, and from then onwards just does what the master does. This log is read later by the slave and contains a collection of statements of what has been executed by the master. Our current server needs to write a log of everything he’s doing from now on. This article however will focus on doing all this via the command line. Note that if you have access to phpMyAdmin on both servers, you’ll be pleased to hear that there’s a much easier and faster way to setup replication. Whenever I issue commands to the OS the cursor prefix is “root# “, and when I’m issuing MySQL commands my cursor prefix is “mysql# ” – hope this makes sense. I’m working on CentOS 6.4 here with MySQL 5.1. There are ways to keep several databases unsynchronized, but this is not covered here. Note that any MySQL data on the slave we’re creating will be wiped out.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |