Subscriptions for restored databases

This procedure only applies to systems where the initial snapshot is transferred manually using a full backup.

Before you begin

You need to restore the iBase entity and link data if you chose to transfer the initial snapshot of data to the subscriber site by using a full backup. Your iBase administrator should have already created an empty iBase database to receive the data.

Perform the restore in the usual way. When you restore:
  • Turn on Overwrite the existing database
  • Leave Preserve the replication settings turned off
After you restore the database, you apply the initial snapshot of data and you are ready to configure a subscription. After you configure the subscription, you must to synchronize the Subscriber with the Publisher.

Procedure

  1. Start a new subscription, either a push subscription or a named pull subscription:
    OptionDescription
    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
  2. Synchronize each Subscriber with the Publisher:
    1. If the Merge Agent is set to use On Demand synchronization, start the Merge Agent manually to upload any changes from the Publisher.
      Note: If there has been many changes at the Publisher, you might want to delay this step until there is a quiet period on your communications link.
    2. Check whether you are synchronized with the Publisher by verifying that a recent change in one of the user tables at the Publisher is replicated to the Subscriber.
  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. Verify that the snapshot has been applied by checking that a rowguid column exists in one of the user tables selected for the article. If this column is missing, check that the snapshot has been applied.
  5. Test that replication is working correctly for the new subscription. Use one of the user-defined tables:
    1. At the Publisher, in one of the user tables (table names do not start with an underscore), change the data in one of the columns for a row. For a new database, carry out this test on the _GlobalConfiguration table and change the version number but take care to change it back to its original value.
    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.
  6. Restrict access to the tables in the SQL Server database. See the Administration Center document Managing Access Control, for details. The information in this document applies to all types of iBase database.
  7. Back up the databases.
    For more information, see:
  8. Tell the iBase administrator that the security data at the Subscriber is configured for replication.