CentOS 7 deploy MySQL 5.7 (master-slave replication, traditional mode and GTID)

Keywords: MySQL Database SQL CentOS

Record (≫); 1. Copy binary files and locations; 2. Master-slave copy based on GTID: (test environment is CentOS 7.3)

I. based on binary log file (traditional way)

(1) working principle:

1. Master records the database operation to Binary log and sends it to Slave I/O thread;
2. Slave's I/O thread stores the received Binary log to the local Relay log;
3. The SQL thread of Slave reads information from the Relay log and updates it locally;

(2) specific configuration

Main database (Master,192.168.100.51):

1,Modify profile
    # vi /etc/my.cnf
    [mysqld]
    #This id needs to be set as unique
    server-id = 1
    #Open binary log
    log-bin = bin-log

2,Create copy account

    //Enter mysql
    create user 'slave' @ '%' identified by 'slavepass';
    grant replication slave on *.* to 'slave' @ '%';

3,See Master Binary file name and location

    show master status;

From database (SLAVE,192.168.100.52):

1,To modify a profile:

    # vi /etc/my.cnf
    [mysqld]
    #This id needs to be set as unique
    server-id = 2

2,configure connections

    # Corresponding to the replication account created by the master database

    mysql> CHANGE MASTER TO
                             MASTER_HOST='192.168.100.51',
                             MASTER_USER='slave',
                             MASTER_PASSWORD='slavepass',
                             MASTER_LOG_FILE='And primary server file Corresponding',
                             MASTER_LOG_POS='And primary server pos Corresponding';

    3,start-up SLAVE

        mysql> START SLAVE;

    4,See SLAVE state

        mysql> SHOW SLAVE STATUS\G;

        //Check whether Slave SQL thread and IO thread are running normally

(3) test

            Create a database in the main database, add tables and data, and check whether the slave database is updated.

2. Global transaction identifier based replication (GTID)

(1) principle

GTID is a new feature referenced by MYSQL 5.6. When a database transaction is committed, a corresponding GTID will be generated in the binlog, the master and slave
When copying, the location of synchronization will be determined from the database through GTID, instead of looking for File and Position. Why is it global? The traditional way of using pos is different between master and slave. For GTID, the same transaction is consistent between master and slave. In this way, when a Master goes down and slave1 is referred to as master, slave2 does not need to find the File and Position of slave1.

(2) specific configuration

Main database (Master,192.168.100.51):

    1,Modify profile

        # vi /etc/my.cnf
     [mysqld]
     #This id needs to be set as unique
     gtid_mode = ON
     server-id = 1
     #Open binary log
     log-bin = bin-log
     enforce_gtid_consistency = ON

 2,Create copy account

     mysql > grant replication slave on *.* to 'slave' @ '%' identified by 'slavepass';

From database (Master,192.168.100.52):

    1,Modify profile

     # vi /etc/my.cnf

     [mysqld]
     gtid_mode = ON
     server_id = 2
     enforce_gtid_consistency = ON

    2,Configure replication connections

    mysql> CHANGE MASTER TO
                             MASTER_HOST='192.168.100.51',
                             MASTER_USER='slave',
                             MASTER_PASSWORD='slavepass',
                             MASTER_AUTO_POSITION = 1;

    3,start-up slave And look at it.

        mysql > start slave;
        mysql > show slave status\G;

Posted by zgkhoo on Sat, 30 Nov 2019 08:01:39 -0800