When to use iBase replication?

Use iBase replication to copy and distribute data across sites and servers.

Replication is a solution if your organization needs to:

  • Copy and distribute data to one or more sites.

  • Distribute data changes to other servers.

  • Allow multiple users and sites to change and then merge the data modifications together, identifying and resolving conflicts if they occur.

Organizations that can benefit from replication include:

  • Organizations with geographically distinct groups of users who need to share common data.

  • Organizations that operate separate iBase databases to overcome practical restrictions that are imposed by iBase when large numbers of users simultaneously access the database.

Replication can also be used to store data redundantly so that part of the organization can continue operating if one or more of the servers or communication links fail. To take advantage of this feature, users need to be able to log on to a remote server.

When to replicate the security data

Replicating the security data means that all sites have the same user groups and users, and adding a user at one site adds that user to the security files at all sites. This can be administered centrally by one security administrator by remote logon, or locally. For more information, see How Security Works in a Replicated Database.

When to replicate the audit log

If you currently use the audit log, you probably want to replicate it. Replicating the audit log allows both analysts and administrators to extend their analysis of the log entries to include changes that are made at any site. For more information, see How the Audit Log Works in a Replicated Database.

If you do not replicate the audit log:

  • Users are only able to analyze log entries made at the local site.

  • Users who need to analyze changes at other sites need to be able to log on to remote servers. This increases the workload for the network administrator (who must grant the users permission to access servers in other domains).

  • Users at the subscriber sites do not see any entries that show how conflicts between entity or link records were resolved.

  • Security administrators might not be able to see how a group or username conflict was resolved if the conflict was detected at a different site. The outcome is recorded in the audit log for the site that detected the conflict. See Handling duplicate group and user names for details of naming conflicts.

Note: Conflict resolution and detection are only logged if the database is set to audit level 4 or 5.

When to use read-only subscription databases

You might want to distribute data and data changes to other servers in your organization but prevent users of that data from changing it. Use iBase database replication to create subscription databases, which are read-only but still receive updates from the Publisher.