CONFIGURING
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:
Related concepts Customizing server-to-server replication Replication and Notes roaming user
Related tasks Scheduling server-to-server replication Creating replicas using the Administration Process Configuring managed replicas