Since January 2017, the MySQL Replication Team has been involved in processing many Community Contributions !
We are really happy to receive contributions (and not only in the replication team), but this also implies a lot of work from our engineers, as more than resolving a bug or developing a new feature, code contributions need to be analyzed, the code needs to be understood and validated. Often it needs to be re-written and finally maintained. This is a long process but we really enjoy it.
Let’s have a look at those contributions we processed in MySQL Replication…
Accepted Contributions
1
| Contribution: |
Add rpl_read_size option |
| Author: |
Santosh Banda |
| Company: |
Facebook Inc |
| Fixed in: |
8.0.5 |
| Manual entry: |
sysvar_rpl_read_size |
| This sets the size for reads done from the relay log and binlog. Making it larger might help with IO stalls while reading these files when they are not in the OS buffer cache. |
2
3
| Contribution: |
DROP TEMPORARY TABLE creates a transaction in binary log on read only server |
| Author: |
Laurynas Biveinis |
| Company: |
Percona |
| Fixed in: |
8.0.4 |
If “DROP TEMPORARY TABLE…” gets executed on server with GTID enabled and read_only mode enabled, then ‘DROP /*!40005 TEMPORARY */ TABLE IF EXISTS sometablename‘ gets inserted in server binary log. This creates errant transaction, that other slaves in cluster might not have and can break replication if server with errant transaction gets promoted to master and this transaction is already deleted from binary logs. |
4
| Contribution: |
Binlog events with binlog_format=MIXED are unconditionally logged in ROW format |
| Author: |
Laurynas Biveinis |
| Company: |
Percona |
| Fixed in: |
8.0.4 |
| When master and slave (with log-slave-updates enabled) are both running with MIXED mode replication and master executes a query that is logged in ROW format, after that query any other query that would be otherwise safe to log in STATEMENT format is unconditionally logged in ROW format for the whole duration of the connection. |
5
| Contribution: |
Using temporary tables on slaves increases GTID sequence number |
| Author: |
Laurynas Biveinis |
| Company: |
Percona |
| Fixed in: |
8.0.4 |
| When ROW binlog_format is used then CREATE statement does not increase the GTID sequence number as the CREATE is not logged to the binary log. However, on connection termination a DROP statement is written to the binary log which increases the GTID sequence number. |
6
7
8
9
| Contribution: |
Request for slave_skip_errors = ER_INCONSISTENT_ERROR |
| Author: |
Tsubasa Tanaka (Oracle ACE) |
| Company: |
GMO Media Inc. |
| Fixed in: |
5.7.19 |
| Replication applier thread returns 3002, ER_INCONSISTENT_ERROR, when there’s difference between expected error number and actual error number. |
10
| Contribution: |
Can’t set slave_skip_errors > 3000 |
| Author: |
Tsubasa Tanaka (Oracle ACE) |
| Company: |
GMO Media Inc. |
| Fixed in: |
5.7.19 |
| MySQL 5.7 has introduced 3000’s error numbers but “slave_skip_errors” doesn’t allow error numbers which is greater than 3000. |
11
12
| Contribution: |
super-read-only does not allow FLUSH LOGS on 5.7 |
| Author: |
Laurynas Biveinis |
| Company: |
Percona |
| Fixed in: |
5.7.18 (part 1) and 5.7.20 (part 2) |
Flush logs command shows the following error when is executed in a slave instance with super-read-only by root user:
ERROR 1290 (HY000): The MySQL server is running with the –super-read-only option so it cannot execute this statement |
13
| Contribution: |
Multi-threaded slave leaks worker threads in case of thread create failure |
| Author: |
Laurynas Biveinis |
| Company: |
Percona |
| Fixed in: |
5.6.38 |
| If one adds SHOW PROCESSLIST to the end of rpl.mts_debug_slave, it will show an orphaned SQL worker thread that is there regardless that the slave is stopped. It is a thread created by mts_worker_thread_fails failure injection point testcase, which tries to set up MTS with two worker threads and simulates a pthread_create failure for one of them. |
14
| Contribution: |
main.mysqlbinlog_debug fails with a LeakSanitizer error |
| Author: |
Laurynas Biveinis |
| Company: |
Percona |
| Fixed in: |
5.6.37 |
| A memory leak in mysqlbinlog. 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. |
Contributions not accepted but issues fixed regardless
We also fixed some bugs receiving contributions but the proposed solutions were not implemented because we already fixed the problem or because we opted for a different fix.
1
2
| Contribution: |
xa rollback with wrong xid will be recorded into the binlog |
| Author: |
HongXiang Jiang |
| Fixed in: |
5.7.21 |
| If we start a XA transaction and prepared it. then, if we do ‘XA rollback’ with the wrong xid, the “XA rollback” will execute failed. but the “XA rollback” has been recorded into the binlog with the right xid. If in the replication, the master do the ‘xa rollback’ with the wrong xid, rollback failed, but on slave, maybe rollback succeed. |
3
| Contribution: |
group commit with GTID enabled need more optimization |
| Author: |
Zhai Weixiang |
| Company: |
Alibaba |
| Fixed in: |
5.7.17 |
| Recently, we are planning to enable GTID on production environment. But while testing the performance impact of GTID, we observed TPS decline… |
As you can see, a large panel of versions were taken into account and I’m happy to see that MySQL 8.0 already receives attention by the Community. Keep this amazing work and together we will keep improving MySQL’s Replication ! Thank you for your contributions !