A view is a replication site that maintains a copy of the replication group's data without incurring other overhead from participating in the replication group. Views are useful for applications that require read scalability, are geographically distributed, have slow network connections to some sites, or require only a subset of replicated databases at some sites.

A client is a participant in the replication group because it helps to determine the master and contributes to transaction durability. A view receives its copy of the replicated data without participating in the replication group in these other ways. Specifically, a view cannot ever become master, a view does not vote in elections, and a view does not contribute to transaction durability. A view is similar to an unelectable client because neither can become master. They differ because an unelectable client participates in the replication group by voting and contributing to transaction durability.

A full view contains a copy of all replicated databases. You define a full view by calling the DB_ENV->rep_set_view() method before opening the environment and supplying a NULL value for the partial_func parameter. You can then complete any other environment configuration, open the environment, and eventually start replication using the DB_REP_CLIENT flags value.

A partial view contains a subset of the replicated databases. You define a partial view using the same steps used to define a full view, except that you supply a partial_func callback to the DB_ENV->rep_set_view() method. The partial function uses application-specific logic to determine the names of the database files to replicate. The partial function should set its result output parameter to 0 to reject a database file or to a non-zero value to replicate it. Note that named in-memory databases are always replicated to partial views regardless of partial function logic.

The decision about whether to replicate a particular database file to a partial view is made at the time the database file is first created. It is possible to change the partial function to replicate a different set of database files. However, any database file that was already being replicated will continue to be replicated regardless of the new partial function logic because it already exists at that site.

Recovery on a partial view should always be performed using the DB_RECOVER flag to the DB_ENV->open() method after calling the DB_ENV->rep_set_view() method to supply the partial function. You should not use the db_recover utility to recover a partial view because it cannot use a partial function.

Defining a site as a view is a permanent decision; once a site is defined as a view it can never be transformed into a participant. This means that on a view site, the DB_ENV->rep_set_view() method must always be called before opening the environment.

An existing participant can be permanently demoted to a view at any time by calling the DB_ENV->rep_set_view() method before opening its environment and starting replication. Demoting a participant to a view can fail when starting replication and return DB_REP_UNAVAIL if the master is unavailable or there are insufficient participants to acknowledge this operation. You can pause and retry starting replication until it succeeds.

A view cannot become master and does not vote in elections, but elections among the participant sites need to know the number of participants in the replication group. Replication Manager automatically manages elections and tracks the number of participants. In Base API applications, the number of sites in the replication group set by the DB_ENV->rep_set_nsites() method should only count participant sites. Similarly, when a participant site calls the DB_ENV->rep_elect() method, the nsites value should only count participant sites. A view should never call the DB_ENV->rep_elect() method.

A transaction's durability within a replication group is based on its replication to other sites that can potentially take over as master if the current master fails. A view cannot become master, so it cannot contribute to transaction durabilty. As a result, Replication Manager views do not send acknowledgements. Base API applications should not count messages returning DB_REP_ISPERM from a view as contributing to transaction durability.

Replication Manager views participate in replication group-aware log archiving. A view can also be configured as a client-to-client peer of another site in the replication group. If a partial view does not contain the information requested, Replication Manager will redirect the request to the master.