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.sync_
.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_ permissions variable
The 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.
This is the default value. -
OFF Non-root users, roles, and groups have to be configured on each aggregator as with previous versions of SingleStore.
Enabling sync permissions
Caution
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
root
and drop all non-root users, if present.Any groups or roles you have created will be removed after you enable sync_
.permissions -
Set the
sync_
variable.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.
Understanding sync users
When 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 USER
command, SingleStore drops the sync user with that name (if one exists). -
If you run a
GRANT
on a user that doesn’t exist, SingleStore will create a sync user with the specified name and then run the grant. -
If you run a
GRANT
orREVOKE
command on the master aggregator, SingleStore will assume the specified user is a sync user. -
If you run a
GRANT
orREVOKE
command on a child aggregator, SingleStore 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