MySQL 5.7并發復制隱式bug實例分析

2024-07-25 19:09:17

字體：大中小

來源：轉載

供稿：網友

前言

我們MySQL線上環境大部分使用的是5.7.18的版本，這個版本已修復了很多bug，但針對主從復制的bug還是有很多的，尤其是一些組復制、并行復制的bug尤為突出，在5.7.19版本有做相應改善和修復。所以建議5.7.19之前的版本還是不要使用mgr和并發復制的功能，如使用建議升級至5.7.19（含）以后的版本。

我這里遇到的問題主要是莫名其妙的數據同步出現問題，無法執行stop slave，數據不一致等現象，經過查看發現是版本bug所致，所以對已上線的從庫關閉并發復制，對未上線的系統實行版本升級。此風險非常非常高，各位務必重視。

具體5.7.19修復的復制bug如下：

參考手冊：https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-19.html

References: See also: Bug #84107.

Replication: In the case of delayed initialization of the Group Replication plugin, deployed in single-primary mode, secondaries were able to get writes through an asynchronous replication channel, which is not allowed in normal initialization of the Group Replication plugin. (Bug #26314756)

Replication: With GTIDs generated for incident log events, MySQL error code 1590 (ER_SLAVE_INCIDENT) could not be skipped using the --slave-skip-errors=1590 startup option on a replication slave. (Bug #26266758)

Replication: A USE statement that followed a SET GTID_NEXT statement sometimes had no effect. (Bug #26128931)

Replication: Groups can now contain members running different server versions to enable you to do online upgrades of a replication group. The rules for combining members in a group with different versions are:

If you have a group with 8.0 members, you cannot add a 5.7 member

If you have a group with 5.7 members you can add a 8.0 member, but it remains in read-only mode. Writing to this member is dangerous while the group contains multiple server versions and should be avoided.

In a single-primary group, if the current primary leaves the group and a new primary must be elected, the primary is first chosen from the lower version members. If no lower version member is found, the primary is chosen from newer version members. (Bug #25876807)

Replication: When binlog_checksum=NONE was set on a MySQL server after startup, and then Group Replication was started, if an error occurred, the server remained in RECOVERING state and could not be shut down. (Bug #25793366, Bug #85667)

Replication: In a Group Replication setup where circular asynchronous replication was implemented between members of different replication groups, view change log events were repeatedly replicated between the groups with new generated GTIDs each time. The fix ensures that view change log events are ignored outside the named replication group where they occur, and never generate new GTIDs. (Bug #25674926)

References: See also: Bug #26049695, Bug #25928854, Bug #25721175.

Replication: When first starting the MySQL server following an installation from RPM, passwword validation plugin is activated by default (true only for RPM installations). If binary logging was already enabled at this time, the activation was logged, even though plugin activations should not be recorded in the binary log. (Bug #25672750)

Replication: In a setup where single-primary Group Replication was combined with asynchronous replication, for example with S1 and S2 forming a group and with S2 and S3 functioning as master and slave, secondaries such as S2 were accepting transactions and these could then enter the group. The fix prevents secondaries creating an asynchronous replication channel when belonging to a single-primary group, and Group Replication cannot be started when asynchronous replication is running. (Bug #25574200, Bug #85047)

References: See also: Bug #86325, Bug #26078602.

Replication: In the event that a member failed to join a group the member was not stopping and continued to accept transactions. To avoid this set your members to have super_read_only=1 in the my.cfg file. Group Replication now checks for this setting upon successful start up and sets super_read_only=0. This ensures that members which do not successfully join a group cannot accept transactions. (Bug #25474736, Bug #84728)

Replication: If the binary log on a master server was rotated and a full disk condition occurred on the partition where the binary log file was being stored, the server could stop unexpectedly. The fix adds a check for the existence of the binary log when the dump thread switches to next binary log file. If the binary log is disabled, all binary logs up to the current active log are transmitted to slave and an error is returned to the receiver thread. (Bug #25076007)

Replication: Interleaved transactions could sometimes deadlock the slave applier when the transaction isolation level was set to REPEATABLE-READ. (Bug #25040331)

Replication: If a relay log index file named relay log files that did not exist, RESET SLAVE ALL sometimes did not fully clean up properly. (Bug #24901077)

Replication: The slave_skip_errors system variable did not permit error numbers larger than 3000. Thanks to Tsubasa Tanaka for the patch. (Bug #24748639, Bug #83184)

Replication: mysqlbinlog, if invoked with the --raw option, does not flush the output file until the process terminates. But if also invoked with the --stop-never option, the process never terminates, thus nothing is ever written to the output file. Now the output is flushed after each event. (Bug #24609402)

Replication: A memory leak in mysqlbinlog was fixed. The leak happened when processing fake rotate events, or when using --raw and the destination log file could not be created. The leak only occurred when processing events from a remote server. Thanks to Laurynas Biveinis for his contribution to fixing this bug. (Bug #24323288, Bug #82283)

Replication: A slave server could lose events not yet applied when MASTER_AUTO_POSITION=0, both replication threads were stopped, and the applier delay was changed using CHANGE MASTER TO MASTER_DELAY=N. (Bug #23203678, Bug #81232)

References: See also: Bug #25340185, Bug #84375.

Replication: Transmission of large GCS messages could take so long the sender appeared to have died. (Bug #22671846)

Replication: Multithreaded slaves could not be configured with small queue sizes using slave_pending_jobs_size_max if they ever needed to process transactions larger than that size. Any packet larger than slave_pending_jobs_size_max was rejected with the error ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX, even if the packet was smaller than the limit set by slave_max_allowed_packet.

With this fix, slave_pending_jobs_size_max becomes a soft limit rather than a hard limit. If the size of a packet exceeds slave_pending_jobs_size_max but is less than slave_max_allowed_packet, the transaction is held until all the slave workers have empty queues, and then processed. All subsequent transactions are held until the large transaction has been completed. The queue size for slave workers can therefore be limited while still allowing occasional larger transactions. (Bug #21280753, Bug #77406)

Replication: An incident event that broke replication was not written to the binary log with a GTID, so that it was not possible to skip the event using SET gtid_next=value. Instead, it was necessary to set the relay log file and relay log positions directly; this meant that, when autopositioning was enabled, it was necessary first to disable it, then to set the relay log file and position, and finally to re-enable autopositioning.

Now in such cases MySQL writes the incident event into the statement cache, so that a GTID is generated and written for it prior to flushing, and that the slave applier works with the change. Then users can skip the event using the SQL statement SET gtid_next=value, followed by BEGIN and COMMIT. (Bug #19594845)

Replication: In certain cases, the master could write to the binary log a last_committed value which was smaller than it should have been. This could cause the slave to execute in parallel transactions which should not have been, leading to inconsistencies or other errors. (Bug #84471, Bug #25379659)

Replication: When using group_replication_ip_whitelist=AUTOMATIC, IPs in the private network are permitted automatically, but some class C IP addresses were not being permitted correctly. (Bug #84329, Bug #25503458)

Replication: When an existing GTID_NEXT transaction was assigned a conflicting GTID by the server, Group Replication generated an assert upon detecting two transactions with same GTID. This was because Group Replication generates the GTID after conflict detection, which is later than with master/slave replication. The fix relaxes some conditions to only be called when commit is done and a message has been added to alert you when a GTID has already been used. (Bug #84153, Bug #25232042)

Replication: The replication applier thread returns Error 3002 ER_INCONSISTENT_ERROR when there is a difference between an expected error number and the actual error number. It is now possible to ignore this error by using 3002 with slave_skip_errors. (Bug #83186, Bug #24753281)

Replication: MySQL lost its GTID position following a restart when a dump from mysqldump had been used to load data.

To keep this problem from occurring, the mysql.gtid_executed table is now excluded automatically from dumps made by mysqldump. (Bug #82848, Bug #24590891)

References: See also: Bug #87455, Bug #26643180.

Replication: Corruption of relay logs for one channel in multi-source replication caused good channels not to be initalized during a server restart. In addition, when run with --skip-slave-start=false, the server also failed to start slave threads for those channels which were in good condition, despite the fact that it should have started the slave threads for all good channels.

Now, regardless of any errors on other channels, the server attempts to create and initialize channels that are in good condition, and starts slave threads for the good channels if --skip-slave-start is disabled. As part of this fix, START SLAVE and STOP SLAVE, which are intended to operate on all channels, are also modified such that they continue executing on all good channels even if they find bad channels among them. (Bug #82209, Bug #24285104)

Replication: The SQL thread was unable to GTID skip a partial transaction. (Bug #81119, Bug #25800025)

Debian client packages were missing information about conflicts with akonadi-backend-mysql packages. (Bug #26002288)