Tips and Tricks

In the above example, the mysqlrplsync utility was used to check all the data on the servers. However, it is possible to check only specific databases and tables. For that purpose, the user only need to specify the target database and tables as arguments when invoking the utility. It is also possible to exclude specific database and tables from the check using the --exclude option. For example, '--exclude=test_rplsync_db,test_db.t0' excludes the database 'test_rplsync_db' and table 'test_db.t0' from the check performed by the utility.

The utility provides important options to control the execution time of the checksum queries performed on each table and the waiting time for slaves to reach an established synchronization point, namely: the --checksum-timeout and --rpl-timeout options. A polling process is applied on each slave to periodically check if replication caught up with the defined sync point. The periodic interval to perform this check can be adjusted with the --interval option. These option are fundamental to control the impact of the execution of the utility on the replication system, limiting the execution time of the checksum queries for large tables and the time slaves wait for replication to catch up. In case, the timeouts defined by those options are reached, the check is skipped. Nevertheless, the user can always execute the utility later only for the skipped tables using higher timeout values.

The utility provides the flexibility to be executed separately for different set of servers, only affecting different parts of the replication system at each time. For example, considering an heterogeneous system (where slaves have a different performances), composed by one master 'M' and three slaves 'S1', 'S2' and 'S3'. To minimize the impact on the master, the user can run the utility first for the master 'M' and the fastest slave 'S1', and then run it again only for the slaves 'S1', 'S2' and 'S3'. If no consistency issues are found in the first execution (M = S1) nor in the second execution (S1 = S2 = S3), then by transitivity and due to the inclusion of the same server 'S1' in both checks it can be said that there is no consistency issues in the all topology (M = S1 = S2 = S3) at the time the first check was completed. This kind of execution must be performed sequentially and not concurrently, otherwise the synchronization process of each instance will likely affect the other and it will not work properly.

User Comments
Sign Up Login You must be logged in to post a comment.