In my last post, I showed how to fix replication errors on slaves, but I’ve made a mistake: my current example wasn’t good, after skipping the command or inserting an empty transaction the dataset was different because of a timestamp holding date column which is the CURRENT_TIMESTAMP default. Fixing the error solved the problem of the running replication thread, but the data wasn’t same on the hosts. I decided to leave this as-is, and instead of recreating the test, I rather show how to sync the databases.
For this, we can use the ‘pt-table-checksum’ and ‘pt-table-sync’ utilities from Percona toolkit.
Continue reading “Syncing differences in MySQL cluster”
Every MySQL DBA should deal with the situation, when there were an accidental write on one of the slaves. Changing replication to GTID will change the way how we should deal with that problem.
Let’s check out!
Continue reading “Fixing broken replication in a GTID based scenario”
Yesterday I’ve put some new features into the ansible’s mysql_replication module because we are planning to move to GTID based replication from the good old binlog position based one, and the module wasn’t aware of.
This parameter can be either 0 or 1, defaults to 0. If set to 1 the replication will be threaded as GTID based replication.
This parameter threats the warnings because of MySQL 5.6 complaints a lot more than the previous versions. (For example, if the replication is not encrypted with SSL/TLS.) This could break our playbooks so you can set it to all, warnings, none (defaults none). Speaks for itself, all means all warnings/errors will be shown, if warnings set, then only the errors will be shown, and the warnings suppressed, and if none then that means, every message will be show up as-is.
If you need it, and you don’t want to wait until it is merged and released, you can download it from my GitHub repository.
We are in the middle of switching to GTID based replication from the good old logfile & log position based replication.
But what is GTID? GTID is an abbreviation of ‘GLOBAL TRANSACTION ID’ what speaks for itself: each transaction of a mysql cluster got its globally unique transaction ID, and the DBA has not spent time with positioning slaves, as well as we don’t have to ‘freeze’ any of the servers because of a master failover. The only thing we have to care about: to know what server should be used as a replication master.
OK, what was the problem with the old file-based replication?
Continue reading “GTID based replication showcase”