I recently looked at how to default a column as a UUID/GUID in MySQL using a trigger, but it's not replication safe when using statement based replication. This post looks at an alternative to using triggers by using a variable instead.
Example table
Let's use the same example table as in the previous post. This is a very basic example table; replace 'tablename' with your actual tablename and add appropriate fields, primary key, change the uuid fieldname, etc.
Using a trigger is not statement based replication safe
As noted in the previous post, if you are using statement based replication between a master & slave (or master & master), the UUID will not be replicated across to the slave server(s) and different UUID(s) will be created on the slave(s).
Why not just use the UUID() function directly in the insert/update query?
You could run this query, for example:
but again, it's not statement based replication safe and the end result will most likely be different UUID values on the master and slave(s).
Set a variable instead
If you set a variable and use that in the insert or update query, then it does appear to be statement based replication safe, which I have tested myself using master-master replication with MySQL 5.5.
So, do this:
Now both the master and slave server(s) will have the same uuid value.
Testing and warnings
These are all the tests I ran:
Using statement based replication, all warnings were the same: "Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it uses a system function that may return a different value on the slave."
However, the last example worked fine, despite this warning:
On the master server:
On the slave server:
0 comments:
Post a Comment