Given "GTID mode is off by default; this is needed to preserve backwards compatibility with existing replication setups (older versions of the server did not enforce any strict mode for binlog order)." as per the manual, it would be good to ensure the change is well documented with the correct procedure for DBA's to follow.

elenst bnestere FYI, and for you feedback if any

knielsen, also fyi and any feedback.

My opinion is that there does not seem to be a lot to be gained by making --gtid-strict-mode the default.

What I see with most users is that they are generally confused by the errors that --gtid-strict-mode enables. Most users are "casual users" that do not have a full understanding on the various nuances around GTID, and do not run a disciplined operations where all application and DBA actions are strictly controlled. Enabling --gtid-strict-mode for these users will just cause their replication to break in ways that do not make sense to them.

A primary goal of --gtid-strict-mode is to serve the smaller group of advanced, disciplined users who want to strictly control all aspects of their operations, and who prefer to get an error immediately (and analyse and understand the error and update procedures to avoid it). These users will know how to enable --gtid-strict-mode themselves.

And apart from those concrete considerations, any change of default causes disruption for existing installations and there needs to be a good reason and clear benefits of such a change to justify it. What are the perceived benefits of this proposed change? Nothing is given in the description regarding this.

knielsen, indeed there were confusion cases that support engineers faced. Largely though they all were about a typical scenario of slave having made unilateral changes to binlog them locally with the replication domain gtid:s. This is the typical error
An attempt was made to binlog GTID 0-101-2197616 which would create an out-of-order sequence number with existing GTID 0-103-2197616, and gtid strict mode is enabled
when replicated from server_id=101 transaction clashes with the slave's server_id=103 one.
Actually I can not dig out anything else that above that our users have been unhappy about while trying the strict mode..
More to that, some big (maybe 'advanced') users (with lots of applications) switched to non-default years ago and so far feel good.

I always thought mixing/logging such slave's local operation together with the replicated events is generally very bad practice from the user pov. It's easy to imagine e.g how failover would seem to work while data consistency lost and may not manifest for some time. Or course the strict mode narrows down possibilities of that which I believe prevails over errors-to-explain like above.

I am not sure though we need to rush the gtid strict mode as default, but I am convinced at least it should be recommended while all its related confusing error explained in the docs.