Thursday, April 23, 2015

Self-Critic and Slides of my PLMCE Talks

The link to the slides of my talks can be found at the end of this post but first, let me share some thoughts about PLMCE.

Talking with people, I was surprised to be criticized of presenting only the good sides of my solution without giving credit to the good side of the alternative solutions.  More than surprised, I was also a little shocked as I want to be perceived as objective as possible.  Let me try to fix that:

  • I am not a GTID and log-slaves detractor, I am a simplicity lover.
  • I actually like GTIDs and I have some use-cases for them; one of  them is described in the MariaDB Knowledge Base (search for last_gtid in that page).
  • But I think that using GTIDs in the slave protocol is complex and that a more simple solution exists (Binlog Servers).  As a simplicity embracer, I choose the latter (I realize that you might not agree with my opinion of more simple but this is a different discussion).
  • Moreover, as the GTID negotiation consumes more resources on the master than the file/position negotiation (this is a fact, not an opinion) and having tens (and sometimes hundreds) of slave replicating from the same master at my current job, a slave reconnection storm is a scenario that scares me with automatic slave positioning with GTIDs.
About log-slave-updates, I see the following use-case (good or bad, we will see later):
  1. High Availability (when combined with GTIDs),
  2. Intermediate Master,
  3. External Trigger with Sequencing,
  4. Storing timing information when merging writes streams,
  5. Converting SBR to RBR,
  6. Testing new MySQL versions.
With reference to use-cases #1 and #2 above (and IMHO), they should be replaced by Binlog Servers to avoid complexity and the consequences of binary log morphing (I talked about binary log morphing in my Lightning Talk, I will come back on that notion in the future but not in this post).  Moreover, in addition to the risk of morphing, intermediate master introduces lag and operation complexity (dealing with their failure and with rogue transactions), thus should be avoided (IMHO).

With reference to use-case #3 (external trigger with sequencing), when needing external triggers and if you can, you should use the binary logs from the master (directly connected to the master or via Binlog Servers).  Actually, a MySQL slave is a specific use-case of external triggers based on the binary logs from the master.  However, if you want to trigger an event after a commit on a slave (which I call sequencing above), log-slave-updates is your best choice so far (very useful for cache invalidation as an example).

With reference to use-case #4, it deserves a post on its own (I might write it when I have time) and could be a valid use-case for log-slave-updates (in very very specific situations IMHO).

With reference to use-case #5 (converting SBR to RBR), log-slave-updates is the only way to achieve that with the current implementation but I see another way coming in the future, I might blog about it.

Finally, with reference to use-case #6 (testing new MySQL versions), it will always be useful but it is not exactly a production use-case.

I need to thanks a few people before closing, they will recognize themselves:
  • Thanks to the people that came to me after my talk and shared their perception about me being a GTID and log-slave-updates detractor: I should have presented things differently and I will in the future.
  • Thanks to the person that thought about the term binary log morphing while he and I were brainstorming about this subject:  I am looking forward to discuss again with you.
  • Thanks to the person that reminded me about the importance of the trigger with sequencing use-case for log-slave-updates: I completely forgot this one and it is a very legitimate use-case.
  • Thanks to the person who opened my eyes on the importance of timing in write stream merging; we have an expression in French for that, it would translate in English to "I understood quickly but you had to spend a long time explaining" which I am grateful for.
Finally, feel free to add a comment below about Binlog Server, my talks and/or this post.  You can also contact me directly via LinkedIn, Facebook or Twitter (my mail is not here for obvious reasons but you can find it in my slides).

You will find the slides of my talks at those links:
And the HOWTO about the MaxScale Binlog Server at those links:

4 comments:

  1. Hi. Excited to hear that the Binlog Server now exists. I will be looking into it.

    I'd love to hear more about an alternate solution for use-case #5 (converting SBR to RBR).

    ReplyDelete
    Replies
    1. About converting SBR to RBR, I am planning to mention this in a future talk that I am currently building. Stay tuned...

      Delete
  2. When you are ready, will you post about it on this blog? I've added your blog to my RSS reader so I will get notified.

    ReplyDelete