On replication, some more

Dear MySQL,

I feel ashamed that I ever wanted you to support 4.0->5.1 replication, and apologize for that. I really understand that it was really egoistic of me even to consider you should be involved in this.

I even understand that 5.0 is running out of active support (I’m not questioning that you’ll stop supporting 4.1 entirely too), and you’ll stop doing pretty much anything to 5.0, except “critical security fixes” (w00t, I managed to get one into 4.1, 8 year old MITM flaw :).

I really understand that supporting more than one release is very very very difficult, and people should do only adjacent version upgrade.

I’m not asking you much, but, maybe you could then support 5.1 to 5.1 replication? I don’t want much, just:

  • Gracefully recover after slave crashes.
  • Don’t have single serial reading of pages for replication stream as a bottleneck – either read-ahead properly (you can do that with RBR!!!), or apply events in parallel (you can do that with RBR too!)
  • Allow to edit replication filters without restarting servers.
  • Allow to enable and disable binary logging of events received from master, as well as enabling and disabling binary logging without restarting the instance.

I hope it isn’t too much too ask! It is just supported replication between two same version instances.

Thanks!

6 thoughts on “On replication, some more”

  1. Hi Domas,

    We have 3 out of 4 of these requirements covered with Tungsten (http://www.continuent.com/community). I’m about to start a series of blog articles on the solution to the second problem, which we plan to deploy early in 2010. Would you mind expanding the specific cases–is it a matter of replication being single threaded, the fact there’s a single client tcp/ip connection from slave to master, etc.?

    Meanwhile, please have a look at Tungsten.

    Cheers, Robert

    1. Hi Domas,

      So, regarding Drizzle, some things in your list above are done, some aren’t. Heck, Drizzle replication is really new, so don’t expect much in terms of features at this point…I’m focusing on fixing bugs and stability over features right now. The nice thing is that the API is very simple and pluggable, and different modules can allow a pretty fine-tuned customization of the replication system.

      That said, I don’t *quite* understand what you are really requesting with this:

      “Allow to enable and disable binary logging of events received from master, as well as enabling and disabling binary logging without restarting the instance.”

      Which of these are yourequesting?

      * to enable/disable ALL logging of events on the SLAVE that have been received from ANY master
      * to enable/disabled logging of SPECIFIC events on the SLAVE that have been received from ANY master
      * to enable/disable the APPLY (not the logging) of specific events on the SLAVE from ANY master
      * something else? :)

      Thanks :)

      Jay

  4. Pingback: Wikipédia : actus diverses « Darkoneko's Weblog

Comments are closed.

%d bloggers like this: