Bug#22857926: ASSERTION `! IS_SET()' AT SQL_ERROR.CC:38 IN
READ_ONLY MODE FOR MANY RPL CMDS.
Problem:
=======
This bug is opened to fix assertion `! is_set()' at
sql_error.cc:380 in "void Diagnostics_area::set_ok_status
(ulonglong, ulonglong, const char*)" for many RPL commands.
This issue has been fixed for couple of commands with
Bug#22097534. But, still issue exists for few other
commands.
Analysis:
========
When the above set of commands are executed they will try
to update replication specific system tables. For example
mysql.gtid_executed
mysql.salve_master_info
mysql.relay_log_info
This scenario is applicable to all replication specific
internal system tables. During the fix for Bug22097534 it
was concluded that "read only" mode should prevent changes
to user data, but not to prevent normal Server operations or
to prevent a DBA from managing the state of the MySQL Server
itself.
Hence the above commands should be able to update data in
replication specific internal tables.
Fix:
===
There exists a flag named 'ignore_global_read_lock' whose
intention is to ignore the read only option and allow
commits to replication specific system tables. Reused
this flag as part of fix. If this flag is set then the
additional check for 'read only' option is not done.
Hence 'read only' mode error will not be reported and
command will complete successfully.
This should be fixed by commit:
commit b24fedd4a043088 f3d9117bea30117 88d4f6531e
Author: Sujatha Sivakumar <email address hidden>
Date: Tue Nov 15 12:01:05 2016 +0530
Bug#22857926: ASSERTION `! IS_SET()' AT SQL_ERROR.CC:38 IN
READ_ONLY MODE FOR MANY RPL CMDS.
Problem: error.cc: 380 in "void Diagnostics_ area::set_ ok_status
=======
This bug is opened to fix assertion `! is_set()' at
sql_
(ulonglong, ulonglong, const char*)" for many RPL commands.
This issue has been fixed for couple of commands with
Bug#22097534. But, still issue exists for few other
commands.
RPL commands affected:- ======= ======= ====== 'aaaaaaaa- aaaa-aaaa- aaaa-aaaaaaaaaa aa:1';
===
[PENDING] 1. FLUSH LOGS;
[PENDING] 2. RESET SLAVE ALL;
[PENDING] 3. SET GLOBAL gtid_purged=
[FIXED] 4. CHANGE MASTER TO..
[FIXED] 5. CHANGE REPLICATION FILTER
[FIXED] 6. START SLAVE;
[FIXED] 7. STOP SLAVE;
Analysis: gtid_executed salve_master_ info relay_log_ info
========
When the above set of commands are executed they will try
to update replication specific system tables. For example
mysql.
mysql.
mysql.
This scenario is applicable to all replication specific
internal system tables. During the fix for Bug22097534 it
was concluded that "read only" mode should prevent changes
to user data, but not to prevent normal Server operations or
to prevent a DBA from managing the state of the MySQL Server
itself.
Hence the above commands should be able to update data in
replication specific internal tables.
Fix: global_ read_lock' whose
===
There exists a flag named 'ignore_
intention is to ignore the read only option and allow
commits to replication specific system tables. Reused
this flag as part of fix. If this flag is set then the
additional check for 'read only' option is not done.
Hence 'read only' mode error will not be reported and
command will complete successfully.