Article directory

Master-slave replication principle + practical operation

Master-slave replication principle + practical operation

What is MySQL master-slave replication?

MySQL master-slave replication means that data can be copied from a MySQL database server master node to one or more slave nodes. MySQL uses asynchronous replication by default, so that the slave node does not have to access the master server all the time to update its own data. Data updates can be performed on a remote connection. The slave node can copy all databases or specific databases in the master database, or specific tables. .

Why is master-slave replication needed?

1. Do hot backup of data. As a backup database, after the main database server fails, it can be switched to the slave database to continue working to avoid data loss.
2. Architecture expansion. The business volume is getting larger and larger, and the frequency of I/O access is too high, which cannot be satisfied by a single machine. At this time, multi-database storage is used to reduce the frequency of disk I/O access and improve the I/O performance of a single machine.
3. Separation of reading and writing enables the database to support greater concurrency. Especially important in reports. Because some report SQL statements are very slow, they cause table locks and affect front-end services. If the front desk uses the master and the report uses the slave, then the report SQL will not cause a front desk lock, ensuring the front desk speed.

Master-slave replication principle

Insert image description here

Execute the start slave command on the slave server to turn on the master-slave replication switch and start master-slave replication.
At this time, the IO thread of the slave server will request to connect to the master server through the replication user permissions that have been authorized on the master, and request to execute the specified location of the binlog log file (the log file name and location are the change master command executed when configuring the master-slave service) After the specified), start sending the binlog log content.
After the master server receives the request from the IO thread of the slave server, the IO thread responsible for replication will read the binlog log information after the specified location of the specified binlog log file in batches based on the information requested by the slave server's IO thread, and then return it to The IO thread on the slave side returns information in addition to the binlog log content, as well as the IO thread recorded on the master server side. The returned information includes the next specified update position in the binlog.
When the IO thread of the slave server obtains the log content, log file and location sent by the dump thread on the master server, it will write the binlog log content to the slave's own relay log relay log file (Mysql-relay-bin). .xxx), and record the new binlog file name and location into the master-info file, so that the next time the new binlog log on the msater side is read, the master server can be told to start reading new binlog files from the specified file and location of the new binlog log. Binlog log content
The slave server-side sql thread will detect the newly added log content of the IO thread in the local relay log in real time, and then parse the content in the relay log file into sql statements in a timely manner, and execute the application on its own slave server in the order in which the sql statements are parsed. sql statement, and record the file name and location of the current application relay log in relay-log.info

Master-slave replication setup (one master and one slave)

1. Prepare two mysql servers

master 192.168.31.153

slave 192.168.31.111

Make sure the mysql service on both servers is started

2. Enable binary logs on the main server

Edit the configuration file /etc/my.cnf, add in mysqld (other fields have been omitted)

master

[mysqld]
log_bin
server_id = 1

slave

[mysqld]
log_bin 
server_id = 2

Notice:

The slave server can disable binary logs
The server_id of the master and slave servers cannot be the same

Restart the mysqld service and refresh the configuration file

[root@slave mysql]# service mysqld restart

question

[root@slave mysql]# service mysqld stop
 ERROR! MySQL server PID file could not be found!

mysqld cannot be restarted—>pid file not found

Reason: After modifying the host name, the original pid file prefixed with the host name cannot be read.

How to solve?

Kill the mysqld process and mysqld_safe process

[root@master backup]# ps aux|grep mysql
root        922  0.0  0.3 115540  1720 ?        S    00:58   0:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/data/mysql --pid-file=/data/mysql/mysql1.pid
mysql      1290  0.0 42.8 1544532 205672 ?      Sl   00:58   0:05 /usr/local/mysq/bin/mysqld --basedir=/usr/local/mysql --datadir=/data/mysql --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=chen.err --open-files-limit=8192 --pid-file=/data/mysql/mysql1.pid --socket=/data/mysql/mysql.sock --port=3306
root       1634  0.0  0.2 112824   988 pts/0    R+   03:10   0:00 grep --color=auto mysql
[root@master backup]# kill -9 922
[root@master backup]# kill -9 1290

Restart the mysql service

[root@master backup]# service mysqld start
Starting MySQL. SUCCESS!

3. Unify the basic data of the two servers

Export all databases of the master to the home directory

[root@master ~]# mysqldump -uroot -p"Sanchuang1234#" --all-databases >all_db.sql
mysqldump: [Warning] Using a password on the command line interface can be insecure.

scp to the home directory of the slave server

[root@master ~]# scp all_db.sql [email protected]:/root/
all_db.sql                                                100%  903KB  63.5MB/s   00:00

Slave server imports sql file

[root@slave ~]# mysql -uroot -p"Sanchuang1234#" <all_db.sql 
mysql: [Warning] Using a password on the command line interface can be insecure.

4. The master server clears all binary files

Because full backup has been carried out and no new data is generated, the old binary log is no longer needed.

root@(none) 03:27  mysql>reset master;
Query OK, 0 rows affected (0.01 sec)

root@(none) 03:27  mysql>show master status;
+-------------------+----------+--------------+------------------+-------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+-------------------+
| master-bin.000001 |      154 |              |                  |                   |
+-------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

5. Create a new authorized user on the master server and copy the binary log to the slave

root@(none) 03:27  mysql>grant replication slave on *.* to 'chenlb'@'192.168.31.%' identified by 'Sanchuang1234#';
Query OK, 0 rows affected, 1 warning (0.02 sec)

192.168.31.% – The network segment where the slave server is located

6.Slave server configuration master info information

root@(none) 03:25  mysql>change master to master_host='192.168.31.153',
    -> master_user='chenlb',
    -> master_password='Sanchuang1234#',
    -> master_port=3306,
    -> master_log_file='master-bin.000001',
    -> master_log_pos=154;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

Parameter meaning

change master to master_host='192.168.31.153' Specify the IP address of the master server

master_user='chenlb' The user authorized by the master server
master_password='Sanchuang1234#' The user password authorized by the master server
master_port=3306 The mysql port number of the master server
master_log_file='master-bin.000001' The binary log being used by the master server
master_log_pos=154 Binary Log position number

7. Check whether the slave is configured successfully

root@(none) 03:43  mysql>show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 192.168.31.153
                  Master_User: chenlb
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: master-bin.000001
          Read_Master_Log_Pos: 154
               Relay_Log_File: slave-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: master-bin.000001
             Slave_IO_Running: No
            Slave_SQL_Running: No

Slave_IO_Running: No slave's IO thread has not been enabled.
Slave_SQL_Running: No slave's sql thread has not been enabled.

8. Start slave

root@(none) 03:43  mysql>stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

root@(none) 03:44  mysql>start slave;
Query OK, 0 rows affected (0.00 sec)

root@(none) 03:44  mysql>show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.31.153
                  Master_User: chenlb
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: master-bin.000001
          Read_Master_Log_Pos: 450
               Relay_Log_File: slave-relay-bin.000002
                Relay_Log_Pos: 617
        Relay_Master_Log_File: master-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Slave_IO_Running: Yes slave enabled successfullySlave_SQL_Running
: Yes slave enabled successfully

Both the IO thread and the sql thread are started, indicating yes.

IO thread and SQL thread failed to start?

possible reason:

Cloning machine causes uuid conflict
Firewall is off
The master info configuration information is incorrectly typed

9. Test the effect of master-slave replication

Create a table and database on the master server, insert data, and check whether the data on the slave server is still consistent. If it is consistent, it is successful.

Main server show processlist;

root@(none) 03:58  mysql>show processlist\G;
*************************** 1. row ***************************
     Id: 6
   User: chenlb
   Host: 192.168.31.111:51274
     db: NULL
Command: Binlog Dump
   Time: 828
  State: Master has sent all binlog to slave; waiting for more updates
   Info: NULL

Main server view port

[root@master ~]# netstat -anplut|grep ES
tcp        0     36 192.168.31.153:22       192.168.31.68:61205     ESTABLISHED 1466/sshd: root@pts 
tcp6       0      0 192.168.31.153:3306     192.168.31.111:51274    ESTABLISHED 2205/mysqld

The slave is always connected to the master. The transport layer protocol uses tcp. Because the connection is established, the account and password used are the account password of the newly authorized user on the master server, which is used to copy the binary log to the slave.

That’s it for the introduction of MySQL master-slave replication. Let’s try setting up mysql master-slave replication! !

MySQL study notes: master-slave replication principle and configuration