Comments on: Using deep nested replication topologies https://shlomi-noach.github.io/blog/mysql/using-deep-nested-replication-topologies Blog by Shlomi Noach Wed, 22 Oct 2014 05:22:36 +0000 hourly 1 https://wordpress.org/?v=5.3.3 By: Pseudo GTID | code.openark.org https://shlomi-noach.github.io/blog/mysql/using-deep-nested-replication-topologies/comment-page-1#comment-283071 Wed, 22 Oct 2014 05:22:36 +0000 https://shlomi-noach.github.io/blog/?p=6865#comment-283071 […] promotion in complex topologies (with deep nested topologies, be able to move a slave up the hierarchy even if its local master is […]

]]> By: shlomi https://shlomi-noach.github.io/blog/mysql/using-deep-nested-replication-topologies/comment-page-1#comment-243394 Tue, 03 Jun 2014 03:27:30 +0000 https://shlomi-noach.github.io/blog/?p=6865#comment-243394 @Jean,
I did note this: “a local master that is lagging for some internal problem will cause all of its slaves to implicitly lag” as well as “Corruption: if a local master gets corrupted, so do all of its slaves. “.

Like I said, you must be willing to pay this price on occasion. When such thing happens we reseed our lost servers.

]]> By: Jean-François Gagné https://shlomi-noach.github.io/blog/mysql/using-deep-nested-replication-topologies/comment-page-1#comment-243326 Mon, 02 Jun 2014 20:30:36 +0000 https://shlomi-noach.github.io/blog/?p=6865#comment-243326 Hi Shlomi, you do not talk about the problem of stalling replication on all slaves of an intermediate master if this intermediate master fails. To my understanding, MHA allows to promote a slave as a new master, but does not reconnect this new master upstream. To be able to do that, I think you need GTIDs (or maybe you solved this problem in another way).

]]> By: shlomi https://shlomi-noach.github.io/blog/mysql/using-deep-nested-replication-topologies/comment-page-1#comment-243255 Mon, 02 Jun 2014 14:24:38 +0000 https://shlomi-noach.github.io/blog/?p=6865#comment-243255 @Massimo,
We’re not using pt-table-checksum on a constant basis. If we do, then it’s of course a slave vs. its direct master.

When we suspect a slave becomes corrupted we destroy it and reseed from a trusted slave.

“Trust” is provided by our application level tests (hourly and daily) which do a lot of cross-referencing and checksuming (again, application-wise) of data. This is not issued against a specific slave but via pool, so every hour a different slave may be picked up.
The above does not cover every possible slave, since tests run within a certain DC. However the fact is that we don’t get slave corruptions, therefore our trust is high.

On certain occasions we run pt-table-sync on specific dates and times. We might start doing so on a scheduled basis.

]]> By: Massimo https://shlomi-noach.github.io/blog/mysql/using-deep-nested-replication-topologies/comment-page-1#comment-243244 Mon, 02 Jun 2014 13:24:44 +0000 https://shlomi-noach.github.io/blog/?p=6865#comment-243244 Hi Shlomi, very interesting as usual. I wonder how you menage the pt-table-checksum utility (if used), is the active master be compared to all slaves or do you use some work around in chain for all the slaves on your topology?

]]>