Kristian Nielsen <kniel...@knielsen-hq.org> writes:
>> Re: https://jira.mariadb.org/browse/MDEV-7145
>> Delayed replication (a feature shipped in MySQL 5.6) has been a MariaDB
> I am planning to look into this.
If anyone is interested, they can track my progress here:
(The current tree has the base feature working (testcase passes), but there
are still a handful of tasks to do).
One issue that turns up is that the feature adds new columns to SHOW SLAVE
Meanwhile, MariaDB has already added other columns, such as Parallel_Mode.
The question then is where in the column list to add the new columns.
I propose to add the new columns at the end of the list output by SHOW SLAVE
STATUS (but before any additional columns output by SHOW ALL SLAVES STATUS).
This is consistent with how other new columns are added in MariaDB, and
preserves the order of existing columns in SHOW SLAVE STATUS.
A possible alternative is to add the new columns in the same relative
positions to existing columns as done in MySQL 5.7. This might be seen as a
way to be more compatible with MySQL; however, the reality is that there are
additional columns in MySQL that are still not in MariaDB after this patch.
So column indexes will still be off between MariaDB and MySQL. With the
additional disadvantage that column indexes for existing columns will
change, and may then change again if additional columns are later merged
So I plan to go with the first approach. This has the benefit that
applications upgrading will not see columns of SHOW SLAVE STATUS shift
positions. Applications can still use the proper column names to be
independent of exact column position.
But let me know if there are other opinions, about column position or
anything else about the patch.
The tree is against 10.1 (but will eventually be pushed into 10.2,
Mailing list: https://launchpad.net/~maria-developers
Post to : email@example.com
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp