Shulou(Shulou.com)06/01 Report--

The problems with MGR can be summarized as follows:

1. When committing a transaction, try to control the amount of data of a single operation transaction, reduce the check time of big things in other nodes and the cluster replication delay caused by blocking later operations, such as transaction rollback has a greater impact.

The deployment of 2.MGR cluster environment is highly dependent on the network, and the network delay will lead to the decline of the performance of the whole cluster. The servers in the cluster should be configured consistently as far as possible, and the poor performance of one of the servers in the cluster will also affect the overall performance of the whole cluster.

During the 3.DDL operation, if the table of the operation has something to execute, all insert, update and delete operations within the ddl time are recorded in a log file, and then these incremental data are applied to the corresponding table (after the transactions on the table are completely released). The log size is limited by the innodb_online_alter_log_max_size parameter. For example, the innodb_online_alter_log_max_size parameter size can not be controlled manually. Will cause ddl execution to fail

4.Mysqldump will directly affect the performance of the cluster, and the occupation of disk io by xtrbackup will also indirectly affect the performance of the cluster. It is recommended that backup nodes consider performing backups on the slave nodes mounted under the mgr cluster.

5. When gtid is enabled, version 5.6 can be upgraded to 5.7.17 and group replication mode can be enabled. Version 5.5 needs to be upgraded to version 5.6 before it can be upgraded to group replication mode. Since the time type time,timestamp,datetime precision is supported to microsecond precision on versions 5.6 and 5.7, the impact of the upgrade from 5.5 needs to be assessed.

6. Data verification. The existing tool Pt-table-checksum does not support the verification of MGR clusters, but can only verify the data of slave nodes.

7. Flow control, flow control will be triggered when the certifer_queue queue depth is greater than flow_crontrol_ certifer_threshold or applier_queue queue depth is greater than the flow_crontrol_ applier_ limit value, and the write will decrease after triggering flow control, which is to avoid greater replication delay, but the front-end application will feel the decline in availability after triggering flow control, so this parameter is a double-edged sword and should be set according to the actual production environment. And there are no monitoring items to monitor the queue depth of certifer_queue and applier_queue for the time being, and the operation and maintenance problems brought about by the later period also need to be considered.

The maximum number of 8.MGR clusters is 9 nodes. Take a 5-node cluster as an example. When 2 nodes in the cluster fail, the remaining 3 nodes can continue to provide services, but when 3 nodes in the cluster fail, the remaining 2 nodes will not be able to provide services. At this time, manual processing is required, such as improper handling is very prone to brain fissure.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.