Synchronizing Permissions Across Your Cluster
On this page
You can ease user account management by automatically keeping non-root user accounts, roles, and groups in sync across your cluster.
GRANT to change a user’s password, and then tries to connect to a child aggregator as that user using the old password, the old password will be rejected.
sync_ global variable defines the behavior of the cluster with respect to local versus cluster-wide, or sync, users.
ON The master aggregator will define and synchronize permissions for non-root users, groups, and roles across all aggregators in the cluster.
OFF Non-root users, roles, and groups have to be configured on each aggregator as with previous versions of SingleStoreDB.
This is the default value.
Deprecation Notice: The
ON will become the default in a future release, and the
OFF setting will no longer be supported.
sync_ set to
ON setting from the start will simplify future upgrades and avoid confusion that can result from having permissions set differently on different aggregators.
Leaves do not use cluster permissions, so setting the
sync_ value on those nodes does not matter.
This is a permanent change.
sync_ is enabled, you cannot turn it off and you can no longer create any local non-root users, groups, or roles.
sync_ is enabled, as the number of users increases, the operations of changing role permissions, roles of a group, user pools, and roles of a user pool tend to consume more time.
sync_ is not recommended if there are more than 100 users (not necessarily concurrent users) on the system.
Connect to the master aggregator as
rootand drop all non-root users, if present.
Any groups or roles you have created will be removed after you enable
permissions Because this is a sync variable, once you set this value, it will be set on all child aggregators in your cluster.SET GLOBAL sync_permissions = ON;
Recreate users, roles, groups, and grants as needed on the master aggregator.
sync_ is set, any new users created will be
sync users, with the exception of the local root user that is still present on each aggregator.
If you run the
DROP USERcommand, SingleStoreDB drops the sync user with that name (if one exists).
If you run a
GRANTon a user that doesn’t exist, SingleStoreDB will create a sync user with the specified name and then run the grant.
If you run a
REVOKEcommand on the master aggregator, SingleStoreDB will assume the specified user is a sync user.
If you run a
REVOKEcommand on a child aggregator, SingleStoreDB will forward the command to the master aggregator and assume the specified user is a sync user.
All of the same semantics apply to sync groups and sync roles as well.
Last modified: November 28, 2022