MDEV-23372: rpl.rpl_skip_replication still fails in buildbot with an extra
warning
Problem:
========
[Warning] Aborted connection 18 to db: 'unconnected' user: 'root' host:
'localhost' (Got an error reading communication packets)
[Note] Start binlog_dump to slave_server(2), pos(, 4), using_gtid(0),
gtid('')
[Warning] Aborted connection 17 to db: 'unconnected' user: 'root' host:
'localhost' (A slave with the same server_uuid/server_id as this slave has
co)
[Warning] Master is configured to log replication events with checksum, but
will not send such events to slaves that cannot process theml
Analysis:
=========
Issue is similar MDEV-14203. MDEV-14203 fix addressed network write error
issue now the same needs to be implemented for network read error.
Fix:
===
Upon network read error donot attempt reconnect, proceed to master-slave
handshake. This ensures that master is aware of slave's capability to use
checksums.
MDEV-26372 enforce-storage-engine=InnoDB has no usability as an option to mysqld-install-db
Creation of tables by the three names mysql.user, mysql.host, mysql.db
was being blocked in the function row_mysql_is_system_table().
Since commit 4abb8216a054e14afbeb81e8529e02bab6fa14ac (MDEV-17658),
mysql.user is a view, not a table. Since commit
ead9a34a3e934f607c2ea7a6c68f7f6d9d29b5bd (MDEV-15851), mysql.host
is not being created at all.
Let us remove the special handling of table names in InnoDB,
and allow mysql.db to be created in InnoDB. The special handling
was originally added in commit e84ef2b747e31235036429760bfda488b82db0bb
without any explanation.
MDEV-20215: binlog.show_concurrent_rotate failed in buildbot with wrong result
Problem:
=======
There are two issues that are addressed in this patch:
1) SHOW BINARY LOGS uses caching to store the binary logs that exist
in the log directory; however, if new events are written to the logs,
the caching strategy is unaware. This is okay for users, as it is
okay for SHOW to return slightly old data. The test, however, can
result in inconsistent data. It runs two connections concurrently,
where one shows the logs, and the other adds a new file. The output
of SHOW BINARY LOGS then depends on when the cache is built, with
respect to the time that the second connection rotates the logs.
2) There is a race condition between RESET MASTER and SHOW BINARY
LOGS. More specifically, where they both need the binary log lock to
begin, SHOW BINARY LOGS only needs the lock to build its cache. If
RESET MASTER is issued after SHOW BINARY LOGS has built its cache and
before it has returned the results, the presented data may be
incorrect.
Solution:
========
1) As it is okay for users to see stale data, to make the test
consistent, use DEBUG_SYNC to force the race condition (problem 2) to
make SHOW BINARY LOGS build a cache before RESET MASTER is called.
Then, use additional logic from the next part of the solution to
rebuild the cache.
2) Use an Atomic_counter to keep track of the number of times RESET
MASTER has been called. If the value of the counter changes after
building the cache, the cache should be rebuilt and the analysis
should be restarted.
Reviewed By:
============
Andrei Elkin: <email address hidden>
