Reset Master and Slave in MySQL GTID Replicate

1 Introduction

After building a server cluster, there are always problems. For a while, there are read and write errors, and for a while, the master and slave are out of sync. Fortunately, it is a personal blog. If it is a team business, it will definitely be greatly affected.

2. Solution

If the data is synchronized, but the master-slave state is abnormal:

Enter the abnormal slave MySQL command line, execute

Comment first then view it after your comment is approved. Join QQ Group to display all hidden texts.

During this process, it is necessary to keep the main library without writing operations, and lock the table if necessary:

1

FLUSH TABLES WITH READ LOCK;

Unlock after copying:

1

UNLOCK TABLES;

3. Summary

Complaints belong to complaints. After clustering, the server pressure has indeed come down. The combination of large bandwidth low performance server + small bandwidth high performance server proved to be the right choice.

In addition, although the operation and maintenance is a bit troublesome, it can guarantee that one machine can be switched directly when it is down, and the unavailability of domestic lines will not affect the access of Google crawlers.

If you use the Pagoda MySQL master-slave replication plug-in, the abnormal master-slave status reported on the plug-in page is generally not a big problem. Wait for ten minutes to check again, and it is generally normal.

If it is not normal, generally delete and add again. If, like me this time, deleting one and the other is abnormal, and adding back the abnormal and the other is normal, try this method.

Last tip: If after resetting the master-slave, it is still displayed abnormally, but there is data in the details, there is a high probability that the master-slave replication has not been started, and the slave must remember to execute start slave.