Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL)
Description
MariaDB partially incorporated an upstream patch to ignore performance_schema.* tables, but the remainder of the patch (which ignored rpl_info tables (and a later patch for gtid )) did not make it into the patch. Probably rightfully so because we don't have the exact same tables they ignored (our patch for reference).
Ultimately, the upstream approach added new table categories, TABLE_CATEGORY_RPL_INFO and TABLE_CATEGORY_GTID, to be ignored in replication.
Attachments
Issue Links
- blocks
-
-
- Closed
-
- relates to
-
-
- Closed
-
Activity
janlindstrom in the case of mariadb-dump (looking at mysqldump.cc), the dump will automatically query either the gtid_binlog_pos or gtid_slave_pos (depending on if using --master-data or --dump-slave), and use that value to generate a new admin command to SET GLOBAL gtid_slave_pos=<that_queried_value>. Is that an option?
bnestere In my opinion not. But maybe we should get back to original problem, why replication of mysql.gtid_slave_pos causes issues and when?
janlindstrom FYI, replicating mysql.gtid_slave_pos has caused MDEV-34924/MDEV-33977, and I also think MDEV-34211. I don't foresee those to be the last either, I think the SST should reference the actual state itself (from gtid_binlog_pos or gtid_slave_pos). It is more efficient than continuously replicating gtid_slave_pos, and I also foresee issues about reconstructing incorrect states if using a replicated table (e..g. from domain ids a long time ago that have been purged from the table would not be added to the state).
bnestere I see, I'm ok you to remove replication of mysql.gtid_slave_pos if you manage to get skip-slave-start=0 to work when Galera cluster is slave to MariaDB master.
Lets assume following topology:
MariaDB master -----async replication ----> Galera node_1 (slave) <---galera replication--->Galera node_2<----galera-->Galera node_3
|
Then if node_1 has skip-slave-start=0 and it goes down. It will do either IST or SST when it comes back online. If mysql.gtid_pos_table
is not replicated node_2 and node_3 do not know correct position. But node_1 does know, therefore we need to read it and pass it to SST/IST request as a parameter. After SST has been done (IST is not a problem here) we need to use passed gtid_pos_table value not the one found from mysql.gtid_pos_table to start slave. Is this doable? Remember there is no user action in automatic slave restart.
bnestere If correct gtid position to continue is possible to generate naturally replication is not necessary. However, my main question is where to get that gtid position? Please remember during SST we copy also binlogs from donor but I do not know how you automatically find out correct gtid position. I would not want such implementation that admin needs to run complicated queries or use mysqlbinlog to find the position, it sounds error prone.