Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Microsoft SQL Server wikipedia , lookup
Serializability wikipedia , lookup
Oracle Database wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Ingres (database) wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Relational model wikipedia , lookup
Concurrency control wikipedia , lookup
Versant Object Database wikipedia , lookup
Database model wikipedia , lookup
Implementation of Database Replication and Binary Logging i4Life Tomas Basham August 13, 2012 Documentation Database Replication and Binary Logging Table of Contents Implementation of Database Replication and Binary Logging ........................................................... 1 Replication Master Device ........................................................................................................................ 3 Replication Slave Device........................................................................................................................... 5 Documentation Database Replication and Binary Logging Replication Master Device This section of the document is a guide through setting up the host machine within the database replication scheme that will act as the master device. The master’s role is to wait for requests from each slave device in the configuration for more data to replicate. When these requests are received the master device sends SQL statements from its binary logs to the slave device for it to reconstruct the database at its end. This setup is to be done before the database is made available to a live system, and should therefore be done offline. After this there should be no reason to take the database offline, except to restore the database if something was to go horribly wrong. Enabling the MySQL process to act as a replication master is very simple, requiring only a few arguments to be added to MySQL’s configuration file. The first step is to open up the configuration file, my.cnf, found under the directory structure /etc/mysql/ and make the following changes: Comment out “skip-networking” and “bind-address” (ignoring the quotes) Uncomment “log-bin = <path/to/binary/logs>” (text in brackets will be an actual path) Uncomment “bin-do-db” and add the name of the database to be replicated e.g. CRi4LifeDev Uncomment “server-id = 1” (make sure that the ID is unique in the replication configuration. If there is more than one device in this configuration, it may result in data not being replicated across all hosts, as some hosts will be hidden behind matching IDs) This will enable MySQL to keep binary logs of all transaction made to the database, and tells MySQL which database is to be replicated. After these changes have been made, save the configuration file and restart the MySQL process. Once MySQL has completely restarted, log into the MySQL shell. A new user needs to be created in order for the replication slaves to access the MySQL database on the master host. Having logged into the MySQL shell issue the following commands: USE mysql GRANT REPLICATION SLAVE ON *.* TO ‘slave_user’@’%’ IDENTIFIED BY ‘slave_password’ FLUSH PRIVILEGES This will create a new user called “slave_user” (minus the quotes) which is identified by the password given. This should obviously be made more secure than the example given above. Now that this is done the host has been setup as a master host for database replication to occur. Now all that remains to do is to make the initial transfer of all the data the database currently stores to a slave host. Before existing the MySQL shell move to the database that is to be replicated by using the USE syntax and run the following command: FLUSH TABLES WITH READ LOCK SHOW MASTER STATUS This creates a lock on all MyISAM table such that all writes to the tables are queued up until the tables are unlocked. This is to ensure no data is written to tables as they are read during the initial copying of the database. The second command that was issued displays a table containing the binary log file name that the database is currently using to log each transaction to the database, along with the current position in the file the database is. Take note if these as they will be needed later for the replication slave. Now that no new data can be written to the tables exist the MySQL shell and backup the database using mysqldump as follows: mysqldump -u root -p --opt --single-transaction “database_name” > ~/backup.sql Documentation Database Replication and Binary Logging This will create a series of SQL statements that can be used to recreate the database. Remember to change “database_name” to the name of the database that is to be backed up. After this has finished backing up the database log back into the MySQL shell and issue the following to unlock all the tables: UNLOCK TABLES Lastly exit the MySQL shell and copy the backup.sql file created earlier to the host that is to be made the replication slave. Documentation Database Replication and Binary Logging Replication Slave Device This section of the document is a guide through setting up the host machine within the database replication scheme that will act as the slave device. The slave’s role is to send requests to the replication master and use the returned data to recreate any changes that have been made. Once the slave is synchronized with the master device it is to be used to make backups. The reason for this is to make backups of the database without interrupting the replication master and therefore not interrupting the cross-mapping tools. Once the backup is made, the slave can be started again, and will continue to synchronize with the master from where it had left off. As with the replication master it is very simple to setup the slave, requiring only a few arguments to be added to MySQL’s configuration file. The first step is to open up the configuration file, my.cnf, found under the directory structure /etc/mysql/ and make the following changes: Uncomment “log-bin = <path/to/binary/logs>” (text in brackets will be an actual path) Uncomment “server-id = 2” (make sure that the ID is unique in the replication configuration) Add “log-slave-updates” underneath log-bin By default the slave will not add to it’s binary logs transactions that are retrieved from the master device. Therefore no binary logs are ever made on the slave device meaning they cannot be used for incremental backups. However the third argument in the above list ensures that all transactions that are made to the slave are logged on the slave thus making the binary logs useful. Once these changes have been made save the configuration file and restart the MySQL process. When the process has successfully restarted the host is now configured as a replication slave. However at this time no updates will be fed through from the master to the slave. This is because the slave has not yet been told where to get updates from and also does not contain the data that is currently on the master device. In order to update the slave log into the MySQL shell and create a database matching the database that is to be replicated (i.e. CRi4LifeDev). Then exit the MySQL shell and issue the following command to restore the database from the backup.sql file that was created earlier: mysql -u root -p “database_name” < backup.sql Having run this command, substituting “database_name” from the name of the database that is to be replicated, the database will be restored to the state of the master when the backup.sql file was created. Once this has finished, log back into the MySQL shell to configure the slave to retrieve updates from the replication master. This is achieved by issuing the following commands: SLAVE STOP CHANGE MASTER TO MASTER_HOST = ‘host_name’, MASTER_USER = ‘slave_user’, MASTER_PASSWORD = ‘slave_password’, MASTER_LOG_FILE = ‘recorded_file_name’, MASTER_LOG_POS = recorded_position SLAVE START Here several substitutions have to be made; host_name should be the hostname or IP address of the replication master host; slave_user should be the username setup on the replication master; slave_password should be the matching password to the user; recorded_file_name should be the name of the file that was recorded earlier after having issued the SHOW MASTER STATUS command within the MySQL shell on the replication master; and recorded position should be number recorded from the same SHOW MASTER STATUS command. N.B. the single quotes above are intentional and should remain even after substitution. If the configuration was successful, the replication slave should now be retrieving updated from the master. Documentation Database Replication and Binary Logging