Note that because of https://bugs.mysql.com/bug.php?id=82848 it is possible to get sudden gaps in the set of gtid’s after a restart if using mysqldump.

Another issue is with filtering: With replicate-do-db etc. the replica still ‘thinks’ it has the full gtid set.

However I do like GTID..

I agree with your sentiments about GTID after fixing some “hostname resolve issues” (which I need to write a blog post about) and basically populated all my GTID boxes with “extra GTID” entries because I had run FLUSH HOSTS.

Hosts are in the P_S.host_cache and are a local cache on the server, so why write this to the binlog? Worse I hadn’t realised that if you do this on the master it pushes the action down to all slaves. Now fixed with FLUSH NO_WRITE_TO_BINLOG HOSTS, but even so some things like this make little sense to me. Required a clean up on all downstream slaves which wasn’t fun.

We need to invite these engineers over to our offices to sit and watch how MySQL is used in real life.

I don’t know how you use MySQL now, though you do know how I manage my boxes and we surely do things differently, both of us having our reasons for doing this or that. A few years of experience installing, fixing, poking and throwing away MySQL servers also gives us a different attitude to the engineers who only build stuff in a “clean room”. Somehow we need to share that knowledge back to them so when they build and design stuff it does not require too many iterations to work the way we want.

That said I have 5 8.0.0 production slaves (different replication chains) running now from 5.7 masters churning away at the moment at the updates that come through in replication. So far they seem to be chugging away quite nicely. That’s certainly an improvement from the .0 releases we’ve seen before. That’s a good start for 8.0…