← Back to team overview

maria-developers team mailing list archive

Re: RFC: new replication feature "per-engine mysql.gtid_slave pos"


In order to document this properly (and in response to https://jira.mariadb.org/browse/MDEV-13236) , I want to clarify a few things:

As I understand it:
* the variable is dynamic, so changes becomes effective immediately
* tables are created immediately whenever a transaction is seen from a specified engine (listed in the variable) * the manual creation of the tables was an initial design suggestion, and there should be no need to ever create a table manually.

I don't have 10.3.1 running yet to test, but some questions:
* what happens if slave threads are not stopped before changing the variable? Just delay the creation of the table, or can something unpleasant happen from a table being created in the middle of something? * what happens if a storage engine is later removed from the variable? If the table still exists, I presume the existence of the table takes priority and the table is still used - the variable is just used to check the existence of a table and create it if needs be, not determine its use? * what benefit does the variable being empty (the default) provide? I saw the comment about the principle of least surprise, but in what way could it being populated and the tables existing be negative? In other words, why would one not simply recommend setting this immediately? * If there is a benefit to it being empty (and therefore no multiple tables created), will there be a mechanism to remove a table beyond manually deleting?

On 03/07/2017 15:15, Kristian Nielsen wrote:
I have now pushed the code to 10.3. It should appear in an upcoming MariaDB
10.3.1 release, IIUC.

Following the discussion so far, the default for --gtid-pos-auto-engines is
currently empty. It can be easily changed later (eg. to
innodb,tokudb,rocksdb) simply by changing the default value in
sql/mysqld.cc. The code will allow this default setting even if eg. tokudb
or rocksdb is not enabled.

(There might be a need to adjust a couple test cases that specially
manipulates mysql.gtid_slave_pos in devious ways).

Let me know in case of any problems or if there are comments/questions.

  - Kristian.

Follow ups