You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 30, 2024. It is now read-only.
Would be possible to manage super_read_only variable by Orchestrator, just like read_only,
Another layer of security to make sure nobody can write the slaves.
Does Orchestrator work if super_read_only is enabled?
Super_read_only was introduced in MySQL 5.7.8 and Percona Server 5.6.21-70. It is not available in MariaDB.
Thanks,
Tibi
The text was updated successfully, but these errors were encountered:
Does Orchestrator work if super_read_only is enabled?
It should; it doesn't write anything to the database itself.
I'm wondering how this should be approached. Should orchestrator set super_read_only whenever we set _read_only? And vice versa? Should this be controlled via configuration flag UseSuperReadOnly: true?
I would definitely like to see a configuration flag like you mentioned: UseSuperReadOnly: true
In that case the customers could control it how they want to use this variable.
Hi,
Would be possible to manage
super_read_only
variable by Orchestrator, just likeread_only
,Another layer of security to make sure nobody can write the slaves.
Does Orchestrator work if
super_read_only
is enabled?Super_read_only
was introduced in MySQL 5.7.8 and Percona Server 5.6.21-70. It is not available in MariaDB.Thanks,
Tibi
The text was updated successfully, but these errors were encountered: