Subscribing to audit publications

You can create either push or named pull subscriptions for an audit log database. When you create the subscription, you should always accept the default options unless specified otherwise in the following instructions (notice that there are no conflicts to resolve in this type of iBase database).

About this task

Note: The audit log database is created automatically when the database that contains the entity and link data is first opened in iBase.

Procedure

  1. Start a new subscription, either a push subscription or a named pull subscription:

    Option

    Description

    Publication

    The database that contains the iBase entity and link data at the Publisher.

    Subscription database

    The existing entity and link database at the Subscriber.

    Select the following options for the subscription:

    • The Subscriber does not have the schema and data and should therefore be initialized.

    • The Merge Agent should continuously check for updates.

    • Use the Publisher as a proxy for the Subscriber when resolving conflicts (described as First to Publisher Wins).

    • The subscription is a client subscription type

    • Depending on the subscription type, set the Merge Agent to initialize the subscription immediately.

  2. Verify that the snapshot is applied by checking that a rowguid column exists in the _ AuditLog table. If this column is missing, check that the snapshot is applied.

  3. Set the Merge Agent for the Subscriber to run at the required frequency, for example a polling interval of 1 second. For more information, see Merge agent for the entity and link database.

    Note: If the iBase database at this Subscriber is read-only, configure the Merge Agent to prevent any uploads to the Publisher. For more information, see Merge agent for a read-only database.

  4. Test that replication is working correctly for the new subscription. Use one of the user-defined tables:

    1. At the Publisher, in the _ AuditLog table, change one of the user names.

    2. After the change is replicated, check the corresponding table at the Subscriber.

    3. At the Subscriber, change the column back to its original value.

    4. After the change is replicated, check the table at the Publisher. If the Subscriber is supposed to be read-only, and the change is merged at the Publisher, check the setting of the Merge Agent.

    5. If the Subscriber is read-only, change the data at the Publisher back to its initial value.

  5. Restrict access to the tables in the SQL Server database. For more information, see Managing access to data and functions.

  6. Back up the databases. For more information, see:

  7. Tell the iBase administrator that the security data at the Subscriber is configured for replication.