Call my on Skype Follow me on Twitter Join me on Facebook Connect with LinkedIn Hire me on UpWork
Richard Wallman - a MySQL® DBA (database administrator)


Blog: Things you probably don't need to do: FLUSH PRIVILEGES
(2018-07-05 11:47:12)
Blog: Why isn't MySQL using the index I expect?
(2018-06-06 10:05:48)
Going to change my policy towards NDAs - I have no problem with them, unless they gag me and create empty spaces in my work history
(2017-08-20 14:27:45)
My week in tags: #cpp #VideoStreaming #handlebarsjs #mongodb #español #holiday #family #perl #nda
(2017-07-02 22:40:00)
Lesson of the week: #MongoDB update() is not the same as SQL UPDATE. It's okay - I didn't need that document anyway 😉#rtfm
(2017-06-25 20:47:31)
My week in tags: #MEAN #MongoDB #JavaScript #NodeJS #expressjs #mustache #PHP #ceph #debian #cpp #html5 #VideoStreaming #fpga #verilog
(2017-06-25 20:38:53)
That was "fun" - setting up new @Percona #MySQL cluster, initial SST kept failing. Culprit: "skip-name-resolve" makes sstuser@localhost fail
(2017-06-20 22:17:45)
Hoping to finally find some time to have a quality play with @percona #MongoDB this weekend - only tested successful install so far
(2017-06-17 15:45:26)
Starting to clear old contracts/NDAs - been quite a year, doing coding, providing training, working with NoSQL databases. Full stack indeed!
(2017-04-21 21:32:02)
Just read the MySQL/HAProxy tutorial on @digitalocean - it's so awful it literally took my breath away for a second. Top result in Google :(
(2016-04-26 15:02:46)

Seems to be an interesting gotcha with binlogs when setting up new nodes in a Percona XtraDB cluster

Posted on 2015-06-16 @ 10:52:00

When the new server starts for the first time, it creates the binlog index file and an initial binlog file. It then connects to the clusters, finds it's not initialised and starts an SST operation. So far, so good...

The issue I've been hitting is that some part of the process is messing directly with the binary log index file, resulting in the new server refusing to start because a binlog file has an incorrect magic number ("Binlog has bad magic number. It's not a binary log that can be used by this version of MySQL"). Digging into it, I've found that something (I believe it's the xtrabackup transfer) is trying to recreate the index file based on a filename match - which is not only picking up the actual binary logs, but the index file as well. The result is a binary log index file that refers to itself, which when the server tries to read as a binary log file, causes it to choke.

My short-term solution is to specify an explicit value for "log_bin_index" to a different directory than the binlogs are being stored in - the new node seems to bootstrap itself happily enough now. There's still an index file being created in the "wrong" place, which isn't getting updated by the server, but the cluster seems happy enough for now.

There's still some weirdness - the binlog from the donor isn't being referenced at all (going to make hanging slaves from the cluster "fun"), the mystery index file, why whatever is doing this isn't picking up on the explicit binlog index file name - but until I get chance to build a minimum test case for this it'll have to wait. I have more nodes to add to this cluster to ensure the ability to form a quorum...

Comments from visitors

Leave your own comment