MDEV-28263: mariadb-tzinfo-to-sql improve wsrep and binlog cases
The --skip-write-binlog message was confusing that it only had an effect if the galera was enabled. There are uses beyond galera so we apply SET SESSION SQL_LOG_BIN=0 as implied by the option without being conditional on the wsrep status. We also with --skip-write-binlog actually check the session @@WSREP_ON variable rather than the global server variable. Since 10.6, the wsrep_mode could replicate Aria and MyISAM, in which case no change to innodb and back is needed. By removing the conditions, we can use LOCK TABLES in a general case improving the load speed of Aria (MDEV-23326), regardless of the skip-write-binlog flag. The only case where we don't use LOCK TABLES is when we are replicating via Innodb, because wsrep_on=1 and wsrep_mode doesn't contain REPLICATE_ARIA{,MYISAM}. This uses an Innodb transaction instead. When replicating via InnoDB we change the table engine type back to what it was originally. By removing the \d and other syntax that requires parsing by the mariadb client, we can use the generated SQL more generally, like in the embedded server. We also save and restore the SQL_LOG_BIN and WSREP_ON session server variables so this can be included in the same session as other data without taking into changes in state. Remove wsrep.mysql_tzinfo_to_sql_symlink{,_skip} tests as they offered no additional coverage beyond main.mysql_tzinfo_to_sql_symlink (no server testing was done). Add galera.mariadb_tzinfo_to_sql to actually test the replication of tzinfo data through galera. The conditional executable comment around /*M!100602 ... START TRANSACTION .. LOCK TABLES.. */ is so that we can provide tzinfo files (MDEV-27113, MDBF-389) and in the case that a user uses it on a pre-10.6 server version it will still work. Both START TRANSACTION and LOCK TABLES are not supported in prepared statements in MariaDB versions earlier than 10.6.2. Reviewed by Brandon Nesterenko
Showing
Please register or sign in to comment