A common replication setup is to have the slaves read only to ensure that no one accidentally updates then. If the slave has binary logging enabled and gid_strict_mode is used, then any update that cause changes to the binary log will stop replication.
When the variable read_only
is set to 1, no updates are permitted except from users with the SUPER privilege or slave servers updating from a master. Inserting rows to log tables, updates to temporary tables and OPTIMIZE TABLE or ANALYZE TABLE statements are excluded from this limitation.
From MariaDB 5.5, if read_only is set to 1, then the SET PASSWORD statement is limited only to users with the SUPER privilege.
Attempting to set the read_only
variable to 1 will fail if the current session has table locks or transactions pending.
The statement will wait for other sessions that hold table locks. While the attempt to set read_only is waiting, other requests for table locks or transactions will also wait until read_only has been set.
Starting with MariaDB 10.3.20 we have fixed some issues related to read only slaves:
read_only
will not be logged even after read_only
mode is disabled (for example if the slave is promoted to a master). If you are using an older MariaDB version with read-only slaves and binary logging enabled on the salve, and you need to do some changes but don't want to have them logged to the binary log, the easiest way to avoid the logging is to disable binary logging while running as root doing maintaince:
set sql_log_bin=0; alter table test engine=rocksdb;
The above changes the test table on the slave to rocksdb without registering the change in the binary log.
© 2019 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.
https://mariadb.com/kb/en/read-only-slaves/