Configuration Analysis of GTID multithreading Based on Linux-6.5

Mysql5.6 Based on gtid master-slave replication (this article is: MariaDB-10) The GTID (GlobalTransactionIDs) introduced by MySQL5.6 makes the configuration, monitoring and management of its replication function easier to implement and more robust. GTID is a unique identifier of a unique. It is globally unique by the uuid of the server and is a 128-bit random identifier.

Mysql 5.6 is based on gtid master-slave replication (this article is: MariaDB-10) The GTID (Global Transaction IDs) introduced by MySQL 5.6 makes the configuration, monitoring and management of its replication function easier to implement, and more robust. GTID is a unique identifier of a unique. It is globally unique by the uuid of the server and is a 128-bit random identifier.

Mysql 5.6 is based on gtid master-slave replication (this article is: MariaDB-10) The GTID (Global Transaction IDs) introduced by MySQL 5.6 makes the configuration, monitoring and management of its replication function easier to implement, and more robust. GTID is a unique identifier of a unique. It is globally unique identifier of the uuid of the server and is composed of 128 random characters, the mysql-5.6 relies on the server-id and uuid to identify each host in the replication architecture, because 128-bit random strings are not repeated globally, server-id and uuid and the transaction serial number of every mysql transaction constitute a unique gtid, since the introduction of mysql-5.6, every binary log will write the gtid mark in the header of every transaction, therefore, gtid makes it easy to track and compare duplicate things and can quickly recover from crashes. In particular, the innodb engine must use gtid to implement high availability.

Mysql's replication

The host environment is:


This blog post is to configure GTID multithreading in MariaDB-10, the following is the configuration steps:


1. Configure MASTER node 1. Configure the Host Name:
2. Stop the service:

3. modify the configuration file:

4. Create a directory and its owner group:

5. Modify hosts:

6. remote replication to the slave Host:

7. test whether the Server Load balancer can be pinged:

8. Start the service:

9. View GTID information:



Ii. Configure SLAVE Node 1. Configure the Host Name:
2. Stop the service:

3. modify the configuration file:

4. Create a directory and modify the owner of the group:

5. Start the service:

6. test whether the master can be pinged:

7. View GTID information:



3. Verify the effect and create an authorized user 1. Create an authorized user on the master:
2. slave points to the specified Copy location:

3. slave start synchronization:

4. Run the slave command to check whether synchronization is enabled successfully:

5. Check whether the mydb database exists in slave:

6. Check the number of slave instances on the master node:

7. Create a master database:

8. Run the slave command to check whether synchronization is performed:


9. At this time, you need to use the following command in combination to see the dynamic results. You can open two windows. Here I may be unable to change because the data volume is too small: 9.1 import large amounts of data from the master:

9.2 slave:

9.3 slave:

9.3.1 comparison:

10. View thread information on the master node:

Click (here) to fold or open

1. MariaDB [(none)]> show processlist;
   
2. 
   
3. + ---- + ------------- + ------------------------ + ------ + ------------- + ------ + Accept + ------------------ + ---------- +
   
4. 
   
5. | Id | User | Host | db | Command | Time | State | Info | Progress |
   
6. 
   
7. + ---- + ------------- + ------------------------ + ------ + ------------- + ------ + Accept + ------------------ + ---------- +
   
8. 
   
9. | 3 | system user | NULL | Connect | 1785 | Waiting for work from SQL thread | NULL | 0.000 |
   
10. 
    
11. | 4 | system user | NULL | Connect | 1785 | Waiting for work from SQL thread | NULL | 0.000 |
    
12. 
    
13. | 8 | repluser | slave.xiaoma.com: 41243 | NULL | Binlog Dump | 954 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL | 0.000 |
    
14. 
    
15. | 17 | root | localhost | NULL | Query | 0 | init | show processlist | 0.000 |
    
16. 
    
17. + ---- + ------------- + ------------------------ + ------ + ------------- + ------ + Accept + ------------------ + ---------- +
    
18. 
    
19. 4 rows in set (0.00 sec)
    
20. 
    
21. MariaDB [(none)]> 11. view the thread information on slave:
    

    Click (here) to fold or open

    1. MariaDB [(none)]> show processlist;
       
    2. 
       
    3. + ---- + ------------- + ----------- + ------ + --------- + Others + ------------------ + ---------- +
       
    4. 
       
    5. | Id | User | Host | db | Command | Time | State | Info | Progress |
       
    6. 
       
    7. + ---- + ------------- + ----------- + ------ + --------- + Others + ------------------ + ---------- +
       
    8. 
       
    9. | 3 | system user | NULL | Connect | 3225828 | Waiting for work from SQL thread | NULL | 0.000 |
       
    10. 
        
    11. | 4 | system user | NULL | Connect | 3225828 | Waiting for work from SQL thread | NULL | 0.000 |
        
    12. 
        
    13. | 6 | root | localhost | NULL | Query | 0 | init | show processlist | 0.000 |
        
    14. 
        
    15. | 7 | system user | NULL | Connect | 1006 | Waiting for master to send event | NULL | 0.000 |
        
    16. 
        
    17. | 8 | system user | NULL | Connect | 535 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL | 0.000 |
        
    18. 
        
    19. + ---- + ------------- + ----------- + ------ + --------- + Others + ------------------ + ---------- +
        
    20. 
        
    21. 5 rows in set (0.00 sec)
        
    22. 
        
    23. MariaDB [(none)]>
        OK !!!