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.
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,
# Throws ER_OUT_OF_RESOURCES ERROR
CREATE VIEW v1 as SELECT * FROM t1;
# The query is still written into bin log.
As the query is written into bin log of master server, it is read by all slaves and the view is created at the slaves(provided no error occurs at slaves) even though it does not exist at master server.
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 is written into bin log of master server, it is read by all slaves and the view is created at the slaves(provided no error occurs at slaves) even though it does not exist at master server.
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?
Elena Stepanova
added a comment - 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?
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.
Sriram Patil
added a comment - 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.
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 is written into bin log of master server, it is read by all slaves and the view is created at the slaves(provided no error occurs at slaves) even though it does not exist at master server.
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.
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.
Sriram Patil
added a comment - 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.
Bug
Major
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?