maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #03629
Re: Live Schema Changes
This is something I'm always interested in. It seems most of us
understand where we need to go, but we don't know yet how to get
there... How do we convince Mark/Mark's boss that this is the best way
to develop MySQL codebase also from Facebook's point of view? (long
term we can make much bigger advances?) Where should this unified
development happen? (MariaDB? Is Maria open enough, responsive enough?
fast enough?)
Kristian, do you want to schedule a "hacking in groups" / unconference
time slot for this?
henrik
On Fri, Sep 24, 2010 at 6:11 PM, MARK CALLAGHAN <mdcallag@xxxxxxxxx> wrote:
> I agree with you about that being the proper way to advance the MySQL
> family and that the MariaDB project has been open and inclusive
> towards external developers like myself. Hopefully, more can come from
> this and this is a topic to discuss in Istanbul.
>
> On Fri, Sep 24, 2010 at 12:51 AM, Kristian Nielsen
> <knielsen@xxxxxxxxxxxxxxx> wrote:
>> MARK CALLAGHAN <mdcallag@xxxxxxxxx> writes:
>>
>>> Define "properly"? I suspect you mean that you want us to spend the
>>> time to get our changes into MariaDB.
>>
>> No, that is not what I meant. I meant write code, tests, etc. like what you
>> and I want to see in the MySQL source. You have often voiced opinions on
>> quality of code, tests, etc., and I believe we think very much alike in this
>> respect.
>>
>> The concrete example was extending the alter table API to better support
>> online schema changes. When we did this at MySQL for online add column in NDB
>> Cluster, we designed it as a general extension to the storage engine API, not
>> as some special case. I think this is what everyone would expect from MySQL
>> sources.
>>
>> But doing such features in a general way, thinking about all use cases and
>> corner cases, can be _much_ more work than making something work well for a
>> given problem at hand. I fully understand the temptation, or even need, to
>> solve the smaller problem instead.
>>
>> My motivation is that I want to see the MySQL source base (under whatever
>> name), see revolutionary improvements long-term. I want to see full parallel
>> replication working with any engine that implements the necessary storage
>> engine API. I want to see a good backup solution that works with different
>> engines. I want to see replication that recovers reliably from crashes and has
>> robust and easy master promotion capabilities. Etc.
>>
>> And I believe to get this we will need not just to add isolated features
>> (whether as individual patches or collected in bzr branches); we will also
>> eventually have to evolve the storage engine API, add new plugin interfaces,
>> etc. That is a lot of work, which is hard to justify for an individual
>> MySQL-using organisation. So I want to encourage everyone to participate in
>> this who might be able to.
>>
>> - Kristian.
>>
>
>
>
> --
> Mark Callaghan
> mdcallag@xxxxxxxxx
>
> _______________________________________________
> 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
>
--
henrik.ingo@xxxxxxxxxxxxx
+358-40-5697354
www.openlife.cc
References