The administrator of the master database should grant to the following rights to master users:
▪ appropriate access rights in the master database to the tables they use for publications and transactions,
▪ execution rights to the procedures they execute.
Note After access rights are granted, they take effect when the user who is granted the rights logs on to the database. If the user is already logged on to the database when the rights are granted, the rights take effect only in the following circumstances:
▪ the user accesses the table or object on which the rights are set for the first time,
▪ the user disconnects and then reconnects to the database.
In the applicable replica database, specify which is the currently active master user by mapping the replica user id with the master user id by using the ALTER USER SET MASTER statement.
When setting up access rights, you can complete the following tasks by using Advanced Replication SQL statements:
Creating access to applications on different masters
In a multi-master environment, you can map a single replica user to a different master user in each catalog. When you change the active replica catalog by using the SET CATALOG statement, the current master user changes automatically.
For example, in a replica database, assume that there is one local user. This user is mapped to the CALENDARUSER master user of the calendar application and the NEWSUSER master user of the news application. The SET CATALOG statement is used to set the current catalog to either CALENDAR or NEWS. If the CALENDAR catalog is set, then the current master user is automatically set to the CALENDARUSER master user. Similarly, if NEWS is set, the current master user is set to NEWSUSER.
Creating user rights to publications and tables
A master user who defines a publication must have read and write access rights to the tables referenced by that publication.
To use a table that is involved in synchronization, the local user must have rights to the actual subscription tables in the replica database, and the corresponding (mapped) master user must have subscribe access rights to the publication in the master database. When subscription rows are inserted (or deleted) in a replica, solidDB verifies that the subscriber has INSERT and DELETE rights on the tables.
The user who defines a publication also has the right to drop that publication.
Creating the replica registration user
When a new Advanced Replication replica database is created, the SYS_SYNC_USERS table of the new database is empty (contains no data). To register the new replica database with the master database and to initially populate the table with data requires a user name that is in the master database and that has registration rights.
You can provide registration rights for a master user in the master database by designating the user with the SYS_SYNC_REGISTER_ROLE or the SYS_SYNC_ADMIN_ROLE by using the GRANT statement, see GRANT.
You must provide this registration user name and password to the replica site that wants to register with the master. This allows each replica site to explicitly set the registration user at the replica with the SET SYNC USER statement, see SET SYNC USER.
Since the user name resides in the master database, this statement allows the registration user to explicitly register the replica. The SYS_SYNC_USERS replica table can then be populated with the public SYS_USERS information from the master database as part of the replica registration process.
When the replica is successfully registered, execute the following statement:
SET SYNC USER NONE
Otherwise, if SET SYNC USER user_name is active and a user saves statements, propagates, refreshes, or registers to a publication, the following error message is returned:
User definition not allowed for this operation.
Note The SET SYNC USER statement is used for replica registration only. Aside from registration, all other synchronization operations require a valid master user ID that has been downloaded to the replica database using the SYNC_CONFIG task. If you want to designate a different master user for a replica, you must map the replica ID on the replica database to the master ID on the master database. For details, see Mapping replica user id with master user id.