[Maria-developers] MDEV-12179: Per-engine mysql.gtid_slave_pos: auto-configuring/packaging
Hello, Suppose there is a transactional storage engine that is shipped as a loadable module. The examples are MyRocks and TokuDB. I think it the default behavior for such engine after MDEV-12179 should be that the engine is listed in @@gtid_pos_auto_engines. That is, as soon as a transaction that uses the storage engine is replicated, mysql.slave_gtid_pos{_$engine} is created for it. gtid_pos_auto_engines makes it easy to do this manually, but it's difficult to achieve as default behavior. Here's an explanation why. Loadable storage engines are put into their separate packages, for example mariadb-plugin-rocksdb_10.2.7+maria-zesty_amd64.deb. The two important files in the package are : ./etc/mysql/mariadb.conf.d/rocksdb.cnf ./usr/lib/mysql/plugin/ha_rocksdb.so The first one is a .cnf that gets included into the server's cnf file. It would be nice to put there something like SET global gtid_pos_auto_engines= CONCAT(@@gtid_pos_auto_engines, 'rocksdb'); but that is not possible (it's a .cnf not .sql) Possible solutions: == [Ab]use the Storage Engine API == Make the storage engine put itself in @@gtid_pos_auto_engines. I think this is technically possible, but - It's a storage engine API abuse - how does one explain @@gtid_pos_auto_engines to the users? == Let gtid_pos_auto_engines include unknown engine == - Allow @@gtid_pos_auto_engines to list unknown engines - set the default to include all known transactional storage engines, that is it should be : gtid_pos_auto_engines='InnoDB,TokuDB,RocksDB' // (*) and the server should allow this even if it is built without TokuDB or RocksDB (*) -- Aria is not needed as it is not a "true" transactional storage engine as far as interplay with the binlog is concerned. == Let packaging use some other solution == I suppose it's possible for packaging system to run some script after a package has been installed. that script might find/adjust my.cnf file to have the desired @@gtid_pos_auto_engines setting. This solution might be complex and fragile, though. Any thoughts ? BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog
Sergey Petrunia <sergey@mariadb.com> writes:
Suppose there is a transactional storage engine that is shipped as a loadable module. The examples are MyRocks and TokuDB.
I think it the default behavior for such engine after MDEV-12179 should be that the engine is listed in @@gtid_pos_auto_engines.
The consensus, in the decisions of the design on the mailing list, was that initially the default should be empty, and that the default could later be changed once we have experience with using the new feature. Personally, I do not have any strong opinion one way or the other. Of course, whether done immediately or later, the issue will need to be addressed eventually.
Possible solutions:
== Let gtid_pos_auto_engines include unknown engine ==
- Allow @@gtid_pos_auto_engines to list unknown engines - set the default to include all known transactional storage engines, that is it should be :
gtid_pos_auto_engines='InnoDB,TokuDB,RocksDB' // (*)
and the server should allow this even if it is built without TokuDB or RocksDB
That is how the patch is currently made. From sql/mysqld.cc: /* For the command-line option --gtid_pos_auto_engines, we allow (and ignore) engines that are unknown. This is convenient, since it allows to set default auto-create engines that might not be used by particular users. The option sets a list of storage engines that will have gtid position table auto-created for them if needed. And if the engine is not available, then it will certainly not be needed. */
Any thoughts ?
Another option could be to allow to specify --gtid-pos-auto-engines multiple times, each use appending to the list. But then, there is no easy way to remove an engine from the list. I think the current solution (allow unknown engine in the list) is an acceptable compromise. Normally, silently ignoring an invalid setting can be bad, because it can lead to surprising behaviour for the user. However, in this case, if an unknown engine is listed in --gtid-pos-auto-engines and is attempted to be used to replicate a transaction, the error will in any case be flagged at that point (it is not possible to access a table using a not loaded engine). - Kristian.
participants (2)
-
Kristian Nielsen -
Sergey Petrunia