Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
Looking at Rdb_binlog_manager in FB/MySQL.
Feature 1: store the master position in MyRocks
It stores the master position in this record:
key: BINLOG_INFO_INDEX_NUMBER
|
value:
|
- binlog_file:position
|
- Last GTID (isn't that a function of binlog position?)
|
Uses for that information:
- It is printed to stderr on server startup (see rocksdb_recover()).
- It is used to move the binlog position forward during recovery:
https://github.com/facebook/mysql-5.6/commit/00861dd66bf37c916558e57caff3875720beebb9
(This targets the usecase with sync_binlog !=1 and innodb_flush_log_at_trx_commit !=1)
- It is visible through INFORMATION_SCHEMA.ROCKSDB_GLOBAL_INFO.
Re #2, InnoDB in FB/MySQL has similar code in is_binlog_advanced (and MariaDB's InnoDB doesn't have it)
Feature 2: keep mysql.slave_gtid_info up to date
When slave-gtid-info=optimized option is used, mysql.slave_gtid_info is kept up-todate directly by the storage engines. (See https://github.com/facebook/mysql-5.6/commit/0f402cb8381ba9d8e71c93085a22e5a12589b6e3)
(Q: and that option is not used, both the SE and the SQL layer do the updates?)
Proposed solution
- Neither of the above features are essential (or storage engine-only)
- MariaDB has an error when trying to use a part of Rdb_binlog_manager (as it doesn't have binlog position stored). We need to disable it.
Attachments
Issue Links
- is part of
-
MDEV-9658 Make MyRocks in MariaDB stable
- Closed
- relates to
-
MDEV-14372 Fix and enable rocksdb.information_schema test
- Open