maria-developers team mailing list archive
Mailing list archive
Re: Tungsten Replicator and MariaDB
I have the same question as Mark, namely: what is the prioritized list of
possible improvements to replication? To answer Mark's other question,
improving replication is work that we (Continuent) would be willing to help
fund. Improvements in this area seem like a great way for MariaDB to
differentiate itself. We would like to help create the list of likely areas
for improvement both in terms of benefits to users as well as how feasible
Here are a few items that I have run into during work in the MySQL binlog.
They may be different from other people as we are parsing the binlog
directly, which is not something that the average user does regularly.
* Event checksums. Binlog corruption does not happen too often but it's bad
when it does. I got it last week during a customer demo. :(
* Column names in table map events. Right now it's just numbers. Not good
for filtering SQL or replication to other databases.
* Keys. Update events in row replication use before/after images but do not
specify keys. This is problematic in a number of cases.
Global transaction IDs and semi-synchronous replication support would also
be high on my list of feature additions for general usability. Fixes for
serious bugs would also be very welcome.
P.s., Mark, do you have a pointer to the extensibility bug(s)?
On 6/20/09 8:00 AM PDT, "MARK CALLAGHAN" <mdcallag@xxxxxxxxx> wrote:
> On Fri, Jun 19, 2009 at 5:46 AM, Arjen Lentz<arjen@xxxxxxxxxxxxx> wrote:
>> Hi Sergey
>> On 19/06/2009, at 8:12 PM, Sergey Petrunya wrote:
>>> On Thu, Jun 11, 2009 at 08:45:08AM -0700, Robert Hodges wrote:
>>>> This brings up a question for the Maria dev team-what are your plans, if
>>>> any, for replication support in MariaDB? In particular, are there any
>>>> plans that would affect binlog formats?
>>> So far we don't have any planned or in-development features that would
>>> an effect on replication or binlog format. MariaDB's replication is
>>> expected to be the same as MySQL replication.
> You can add support for binlog checksums without breaking
> compatibility because the format is extensible. Alas, extensibility is
> broken because of bugs, so when those bugs are fixed I think you can
> do this. However ...
>> This is the real world, and pragmatism is expected.
>> Things are broken in the land of MySQL replication, and thus we should fix
>> The fixes are actually available, so why even bother coming up with excuses?
>> Yep it changes/extends the binlog format. Tough! It's an upgrade; just like
>> any other, a newer server should be able to be a slave to an older master.
>> But this is important stuff! For instance, adding checksums to the binlog
>> prevents a whole load of trouble. Not having it in there since the start
>> (yes SashaP, I know you're guilty - plus all those who reviewed your code at
>> the time) is a 10 year embarassment. Let's get it right, now, shall we?
> Time is finite and the work to do on MySQL is not. It is not that hard
> to do this feature, but who has the time to do it? And if nobody has
> the time for it, then who is funding it?
> Does MariaDB have a list of pending work ranked by priority?
> Mark Callaghan
> Mailing list: https://launchpad.net/~maria-developers
> Post to : maria-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help : https://help.launchpad.net/ListHelp
Robert Hodges, CTO, Continuent, Inc.
Mobile: +1-510-501-3728 Skype: hodgesrm