Log in

No account? Create an account

Master.info, Re-factoring Code

« previous entry | next entry »
Oct. 7th, 2008 | 09:55 pm

I was just able to do this for the first time:

[root@piggy var]# /tmp/drizzle/drizzled/serialize/master_list_reader ./master.info
HOSTNAME piggy.tangent.org
PORT 4427

So what is the big deal?

In the reworking of replication I ran across this bird's nest of a code that exists for the master.info file. Pretty much all of the code dates back to around 2000 (despite the recent work in row based replication, most of the code in replication has been the same for the last eight years).

One of the things no one has ever tackled was getting rid of the master.info file. Even at this point in Drizzle we still have it, though we have moved it to being a protocol buffer file and now can list multiple masters in the file (so yes, that means we will most likely have multi-master support sometime shortly).

In the next few months this file will go away and we will move the data into a table, but for now it was worth spending the two days to clean up the code in order to get rid of the "master database server has died and forgotten to write out the correct data" problems that have existed for so long. I suspect we will evolve the interface at least two more times before we are done. Sure I could shoot for the "end design" and try to be done with it, but I have found that attacking our problems in bite size chunks tends to buy us more distance than just tearing it out and hoping to find the one "right way" for the solution.

I am starting to wonder what the rule of thumb should be for refactoring. The code base we are working from last evolved over a decade ago. This was when Unireg became MySQL. I am starting to think we should be spending anywhere between 70 and 80 percent of our time going forward on just refactoring work. This does not leave a lot of room for features, but I believe that features are a lot less important then what people make them out to be (and in our case we are just working on the micro-kernel, so others can continue innovate on the edge).

The older the code base gets the more important it becomes to do this sort of work, though I am sure someone a decade from now is going to find themselves just as annoyed as I am most days :)

Link | Leave a comment |

Comments {7}


(no subject)

from: sent2matt
date: Oct. 8th, 2008 07:11 am (UTC)

> o yes, that means we will most likely
> have multi-master support sometime shortly

When do you expect this as a patch or something
(not asking of mysql distribution)?

Do you think one should wait for this or in the meanwhile
try to use mysql proxy to do multi-master replication?

Reply | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: Oct. 8th, 2008 07:42 am (UTC)

We are still not in a state where I want anyone using us (not that this stops people). I think we are still a few months off from being there. I've got a list I publish to our mailing list every so often which goes over the details of "this is where we are at".

Reply | Parent | Thread