From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/rep_partview.html | 169 ++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 docs/programmer_reference/rep_partview.html (limited to 'docs/programmer_reference/rep_partview.html') diff --git a/docs/programmer_reference/rep_partview.html b/docs/programmer_reference/rep_partview.html new file mode 100644 index 00000000..8da359a7 --- /dev/null +++ b/docs/programmer_reference/rep_partview.html @@ -0,0 +1,169 @@ + + + + + + Replication views + + + + + + + + +
+
+

Library Version 12.1.6.1

+
+ + + + + + + + + +
Replication views
Prev Chapter 12.  Berkeley DB Replication  Next
+
+
+
+
+
+
+

Replication views

+
+
+
+

+ 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. +

+
+
+
+ + + + + + + + + + + +
Prev  + Up +  Next
Managing Replication Manager + group membership  + Home +  Managing replication directories and files
+
+ + -- cgit v1.2.1