maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #08591
Re: Features Wish-list in MariaDB 10.1.
-
To:
MariaDB Developers <maria-developers@xxxxxxxxxxxxxxxxxxx>
-
From:
Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>
-
Date:
Fri, 22 May 2015 12:42:38 +0200
-
In-reply-to:
<555EFB7E.6080400@booking.com> ("Jean-François Gagné"'s message of "Fri, 22 May 2015 11:48:46 +0200")
-
User-agent:
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
So my opinion on these below two points was requested, let's keep it on the
public mailing list:
> * Crash-Safe replication with filename and position (not depending on
> GTIDs)
> Something similar as what is described in the following link would
> be good:
> http://blog.booking.com/better_crash_safe_replication_for_mysql.html
> * Have a way to avoid "SELECT binlog_gtid_pos" when a slave connect to
> the master in MASTER_USE_GTID = no
So my personal opinion on this is that I prefer to focus on improving the
MariaDB GTID implementation. Considerable effort was invested into this, and
the idea is that future development will focus on GTID mode, keeping
non-GTID mode only as a backward compatibility. Significant effort was made
to ensure that MariaDB GTID is usable for all existing use-cases of
replication.
For the first point, GTID replication is already crash-safe.
For the second point, for GTID we in any case need a solution for locating
GTID position quickly, otherwise GTID replication can have performance
problems in case of frequent slave connects (and Jonas Oreland has promised
a patch for this any day now ;-). And once this solution is in, the second
point should be moot anyway.
Of course, others may have a different opinion. For the second case, I
suppose the easiest thing is just to remove the code that does SELECT
binlog_gtid_pos() from the slave, if no-one cares about that functionality
anyway...
Hope this helps,
- Kristian.
Follow ups