The ALTER USER replica_user ... statement is used to map replica user ids to specified master user ids. It is always a replica user id that is mapped to a master user id.
The mapping of user ids is used for implementing security in a multi-master or multi-tier synchronization environment. In such environments, it is difficult to maintain the same username and passwords in separate, geographically dispersed databases.
Only a user with DBA authority or SYS_SYNC_ADMIN_ROLE can map users. To implement mapping, an administrator must know the master user name and password. If NONE is specified, the mapping is removed.
All replica databases are responsible for subscribing to the SYNC_CONFIG system publication to update user information. Public master user names and passwords are downloaded during this process to a replica database using the MESSAGE APPEND SYNC_CONFIG command. Through mapping of the replica user id with the master user id, the system determines the currently active master user, based on the local user id that is logged to the replica database. If during SYNC_CONFIG loading the system does not detect mapping, it determines the currently active master user through the matching user id and password in the master and the replica.
For more details on using mapping for security, see “Implementing security through access rights and roles” in the solidDB® Advanced Replication User Guide.
You can also limit which master user accounts are downloaded to the replica during SYNC_CONFIG loading. This is done by altering the status of users as private or public with the following command: ALTER USER username SET PRIVATE | PUBLIC
The default is PUBLIC. If the PRIVATE option is set for a user, that user’s information is not included in a SYNC_CONFIG subscription, even if they are specified in a SYNC_CONFIG request. Only a user with DBA authority or SYS_SYNC_ADMIN_ROLE can alter a user’s status.
This allows administrators to ensure that no user ids with administration rights are sent to a replica. For example, for security reasons, administrators might want to ensure that DBA passwords are never public.
Usage in master
In a master database, you can set user ids to PUBLIC or PRIVATE.
Usage in replica
In a replica database, you can map a replica user id to a master user id.
Examples
The following statement maps a replica user id smith_1 to a master user id dbawith the password of the user DBA.
ALTER USER SMITH_1 SET MASTER MASTER_1 USER DBA IDENTIFIED BY DBA
The following statement sets the status of the user admin1 of the master database to PRIVATE, defining that the user account of admin1 should not be downloaded to any replica. ALTER USER admin1 SET PRIVATE;
The following statement sets the status of the user salesman of the master database to PUBLIC, defining that the user account of salesman should be downloaded to allreplicas.