Replicas

You can make a database available to users in different locations, on different networks, or in different time zones, by creating replicas of the database.

All replicas share a replica ID which is assigned when the database is first created. The file names of two replicas can be different, and each replica can contain different documents or have a different database design; however, if their replica IDs are identical, replication can occur between them.

As users add, edit, and delete documents in different replicas of a database, the content in the replicas is no longer identical. To ensure that the content in all replicas remains synchronized, you use Connection documents to schedule replication between the servers that store the replicas. Then multiple sites, teams, and users can make changes to a database and share those changes with everyone else who has access to that database. In addition, using replicas and scheduling replication reduces network traffic. Users never need to connect to a single central server that stores the only replica of a particular database. Instead, they can access a replica of that database on one or more local servers.

These distributed replicas can also be Web sites that are hosted on different Domino® servers. Then users aren't dependent on one server when they attempt to access critical applications over the Internet. If one server is unavailable, users can access another replica of the database on another server. You can also use replicas to help manage ongoing Web site design. On one server, you can set up a Web staging area where you design and test new pages. When the design changes are tested and ready to be released, you can replicate this server with the server storing the replica of the Web site that is available to users. By using replicas and replication this way, you prevent Web users from seeing your "work-in-progress."

A replica of a database isn't the same as a copy of a database that you make by choosing File > Application > New Copy. Although a copy of a database may look the same as the original database, a copy doesn't share a replica ID with the original database and so it can't replicate with it.

Deciding when to create a replica

Plan your replica strategy carefully, and create replicas on servers only when necessary. The more replicas, the greater the demand on server and network resources and the greater the need for additional maintenance. To prevent unnecessary proliferation of replicas, assign Create Replica server access to only a few administrators. Then tell users and application developers to send their requests for new replicas to these administrators.

Create a replica of a database to:

• Improve performance of a heavily used database.
• Distribute network traffic.
• Keep a database that you're redesigning separate from a production version of the database.
• Keep a database available even if one server goes down.
• Make a database available to users in remote locations.
• Provide a replica containing only a subset of information that is relevant to a particular workgroup.
• Set up Domino® system administration -- for example, you must create replicas of the Domino® Directory, the Administration Requests database, and other critical system databases.
• Place a replica of a master template on each server that stores a database that inherits from the master template.
• Create a backup database from which you can restore information if data becomes corrupted; since corrupted data often replicates, use this only as a secondary backup method.

Keep in mind that two replicas will contain slightly different content between replications. If users need access to the most up-to-date information in a database, you can create replicas on clustered servers and then set up replication in clusters. In a cluster, all replicas are always identical because each change immediately replicates to other servers in the cluster.