Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5.38, 10.0.12
-
None
-
None
Description
While creating VIEW, msql_register_view method is invoked for creating .frm and process .frm's history backup. This method returns errors like, ER_OUT_OF_RESOURCES, ER_TABLE_EXISTS_ERROR, ER_NO_SUCH_TABLE, etc.
Even if an error is returned by this method, query is written in the bin log. So consider an example,
CREATE VIEW v1 as SELECT * FROM t1;
-> Throws ER_OUT_OF_RESOURCES ERROR
-> The query is still written into bin log.
As the query with the error is written into bin log of master server, it is read by all slaves and causes a conflict if same error is not generated at a slave server. This results in replication abort.
Attachments
Activity
Yes, the replication aborts due to contradiction in errors. But, the replication should not stop at this point. The query should not be written into the log. The query is logged only when the query is successful. And the error occurs mainly when the VIEW is not created on master. So, ER_TABLE_EXISTS_ERROR should not cause a problem. ER_OUT_OF_RESOURCES will generate a conflict.
I will change the description to mention that the replication aborts.
The version was not set before. Sergei suggested me to set it to the first search that appears after typing "5.5". And galera appeared first. That is the only reason I have set it to 5.5.38-galera.
I checked with ER_TABLE_EXISTS_ERROR on 5.5, the statement is written to the binary log, but with the error code, so it shouldn't cause any data discrepancy between master and slaves (generally, replication should abort if the statement does not finish with the same error on slaves).
Does it contradict your observations?