Skip to main content

How to Configure MySQL Master/Slave replication on CentOS 7

MySQL replication is a process that allows you to easily maintain multiple copies of MySQL data by having them copied automatically from a master to a slave database.

This post assumes that you have a user with sudo privileges and have not installed MySQL. If you do have MySQL installed, then you can skip the installation step and move to the configuration of master/slave database:

MySQL installation on the MASTER server

Install MySQL server and MySQL client:

# yum install mysql-community-server

Connect to MySQL shell in order to create the new user “dbuser” and the database “testdb”:

# mysql -u root -p
mysql> create database testdb;
mysql> grant usage on *.* to dbuser@localhost identified by ‘password’;
mysql> grant all privileges on testdb.* to dbuser@localhost;
mysql> exit;

Edit the MySQL configuration file to allow remote connections to this server:

# vi /etc/mysql/my.cnf

Find the line “bind-address = 127.0.0.1” and comment it if it’s not already done:
#bind-address = 127.0.0.1

MySQL installation on SLAVE server

For the moment, just install MySQL server and MySQL client on the SLAVE server:

# yum install mysql-community-server

Configure MySQL replication on the MASTER Database server

Edit the MySQL configuration file to enable master database replication:

# vi /etc/mysql/my.cnf

Find the line “server-id” and set it to 1:

server-id = 1

Move on to the "log _ bin" line.
This is where the real details of the replication are kept. The slave is going to copy all of the changes that are registered in the log. 
For this step we simply need to uncomment the line that refers to "log _ bin" and add the "expire _ logs _ days" to avoid a huge amount of log files filling up the disk:

log-bin = mysql-bin.log
expire_logs_days = 7

Finally, we need to designate the database that will be replicated on the slave server. You can include more than one database by repeating this line for all of the databases you will need:

binlog_do_db = testdb

After making all of the changes, go ahead and save and exit out of the configuration file, then restart MySQL service.

# service mysql restart

The next steps will take place in the MySQL shell, itself. We will grant privileges to a new “slave_user” who will be used for the replication (please choose a password):

# mysql -u root -p
mysql> grant REPLICATION SLAVE on *.* to 'slave_user'@'%' IDENTIFIED BY 'password';
mysql> flush privileges;

To continue, please open a new SSH connection to the master server, in a new shell window.
In your current SSH window, switch to testdb database and lock the database to prevent any changes:

mysql> use testdb;
mysql> flush tables with read lock;

Then type:

mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      403 | tesdb        |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
You will see a tab with some information. The important one is "Position". This is the position from which the slave database will start replicating. We will use this position number later.

If you make any new changes in the same SSH window, the database will automatically unlock. For this reason, you should open the new tab or window and continue with the next steps there.

Proceeding with the database still locked, export your database using mysqldump in the new window (make sure you are typing this command in the bash shell, not in MySQL).

# mysqldump -u root -p --opt testdb > testdb.sql

Now, returning to your original SSH window, unlock the databases (making them writeable again). Finish up by exiting the shell:

mysql> unlock tables;
mysql> exit;

Now you are all done with the configuration on the master side.

Configure MySQL replication on the SLAVE Database server

Log into your slave server, open up the MySQL shell and create the new database and user (same as before):

# mysql -u root -p
mysql> create database testdb;
mysql> grant usage on *.* to dbuser@localhost identified by ‘password’;
mysql> grant all privileges on testdb.* to dbuser@localhost;
mysql> exit;

Import the database that you previously exported from the master server:
# mysql -h localhost -u root -p testdb < testdb.sql

Now we need to configure the slave configuration in the same way as we did for the master:

vi /etc/mysql/my.cnf

Find the line “bind-address = 127.0.0.1” and comment it if it’s not already done:

#bind-address = 127.0.0.1

Find the line “server-id” and set it to 2:

server-id = 2

Following that, make sure that you have the following 4 criteria appropriately filled out: (You will need to add the last 2 lines which are not there by default.):

log-bin = mysql-bin.log
binlog_do_db = alfresco
relay-log = mysql-relay-bin.log
relay_log_space_limit=2G

After you make all of the changes, go ahead and save and exit out of the configuration file, then restart MySQL service.

# service mysql restart

The next step is to enable the replication from within the MySQL shell.

Open up the MySQL shell once again and type in the following command, replacing the values to match your information which is in the previous tab (on the master):


mysql> CHANGE MASTER TO MASTER_HOST='192.168.56.62',MASTER_USER='slave_user', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=  403;

This command accomplishes several things at the same time:
  • It designates the current server as the slave of our master
  • It provides the server with the correct login credentials
  • It lets the slave server know where to start replicating from
With that, you have configured the master and slave server. Activate the slave server:

mysql> start slave;

You can see the details of the slave replication by typing in the following command.
The \G rearranges the text to make it more readable.

mysql> show slave status\G

You should have something like this:



Thanks!!

RANDYDBA BLOG { DATABASE - TIPS & TECHNIQUES }
serving to discover










Comments

Popular posts from this blog

Oracle Database 19c Step by Step Installation On Oracle Linux 7.6

This post describes the installation of Oracle Database 19c 64-bit on Oracle Linux 7.6  x86-64 bit. The Linux server needs a minimum of 3G swap and secure Linux set to permissive. An example of this type of Linux installation can be seen here . Download Software Download the Oracle software from oracle edelivery . Oracle Installation Prerequisites Automatic Setup Use the "oracle-database-preinstall-19c" package to perform all your prerequisite setup. # yum install -y oracle-database-preinstall-19c If you are using RHEL7 or CentOS7, you can pick up the PRM from the OL7 repository and install it. It will pull the dependencies from your normal repositories. # yum install -y https://yum.oracle.com/repo/OracleLinux/OL7/latest/x86_64/getPackage/oracle-database-preinstall-19c-1.0-1.el7.x86_64.rpm Hosts File Set a fully qualified name for the server in the "/etc/hosts" file. < IP-address > < fully-qualified-machine-name > < machin...

How to Delete Old Trace & Dump files with ADRCI

The ADRCI command interpreter has multiple features:- Create a package with incident or problem information for Oracle Support Analyze diagnostic data within the Automatic Diagnostic Repository (ADR) Run health checks In this post, we'll be concentrating on deleting the old diagnostic files with ADRCI. Set your environment and run the ADRCI utility: $ adrci Use the following command to list the ADR homes: adrci> show home ADR Homes: diag/rdbms/db11g/DB11G diag/tnslsnr/sol10/listener Choose the ADR home from the list above: adrci> set home diag/rdbms/db11g/DB11G Check the current retention policy: adrci> show control Check the following columns in the output: LONGP_POLICY:- It is set to 365 days by default. It is responsible for Incidents and Health Monitor warnings. SHORTP_POLICY:- It is set to 30 days by default. It manages the trace and core dump files. Use the following commands to change the retention policy: Specify the time in hours: 10 Days = 240 ...

Oracle Database 12C Error Codes, Solutions and Suggestions from ORA-19700 to ORA-20000

Oracle 12C Error Codes, Solutions and Suggestions from ORA 19700 to ORA 20000 ORA-19700: device type exceeds maximum length of string Cause:  The device type indicated is invalid. Action:  Supply a correct device type and retry the allocation. ORA-19701: device name exceeds maximum length of  string Cause:  The device name indicated is invalid. Action:  Supply a correct device name and retry the allocation. ORA-19702: device parameter exceeds maximum length of  string ORA-19703: device command string exceeds maximum length of  string Cause:  The device command string exceeds maximum length. Action:  Correct the command and retry the operation. ORA-19704: file name exceeds maximum length of  string Cause:  The specified file name, which was a parameter to a copy, backup, or restore operation, exceeds the maximum file name length for this operating system. Action:  Retry the operation with a s...