Library Version 11.2.5.3

Library Version 12.1.6.1

- + - +

Synchronizing with a master			Synchronizing with a + master
Prev	Chapter 12. - Berkeley DB Replication -	Chapter 12. Berkeley DB Replication	Next

@@ -34,7 +33,8 @@

Synchronizing with a master

Synchronizing with a + master

@@ -52,21 +52,25 @@

- Blocked client operations + Blocked client operations

- Clients too far out-of-date to synchronize + Clients too far out-of-date to synchronize

When a client detects a new replication group master, the client must -synchronize with the new master before the client can process new -database changes. Synchronizing is a heavyweight operation which can -place a burden on both the client and the master. There are several -controls an application can use to reduce the synchronization burden.

+ When a client detects a new replication group master, the + client must synchronize with the new master before the client + can process new database changes. Synchronizing is a + heavyweight operation which can place a burden on both the + client and the master. There are several controls an + application can use to reduce the synchronization + burden. +

@@ -75,21 +79,30 @@ controls an application can use to reduce the synchronization burden.

When a replication group has a new master, either as specified by the -application or as a result of winning an election, all clients in the -replication group must synchronize with the new master. This can -strain the resources of the new master since a large number of clients -may be attempting to communicate with and transfer records from the -master. Client applications wanting to delay client synchronization -should call the DB_ENV->rep_set_config() method with the -DB_REP_CONF_DELAYCLIENT flag. The application will be -notified of the establishment of the new master as usual, but the -client will not proceed to synchronize with the new master.

Client applications choosing to delay synchronization in this manner are -responsible for synchronizing the client environment at some future time -using the DB_ENV->rep_sync() method.

+ When a replication group has a new master, either as + specified by the application or as a result of winning an + election, all clients in the replication group must + synchronize with the new master. This can strain the + resources of the new master since a large number of + clients may be attempting to communicate with and transfer + records from the master. Client applications wanting to + delay client synchronization should call the DB_ENV->rep_set_config() + method with the DB_REP_CONF_DELAYCLIENT flag. The + application will be notified of the establishment of the + new master as usual, but the client will not proceed to + synchronize with the new master. +

+ Client applications choosing to delay synchronization in + this manner are responsible for synchronizing the client + environment at some future time using the DB_ENV->rep_sync() + method. +

@@ -99,92 +112,125 @@ using the DB_ENV->rep

Furthermore, when the other client receives such a request it may be -unable to satisfy it. In this case it will reply to the requesting -client, telling it that it is unable to provide the requested -information. The requesting client will then re-issue the request. -Additionally, if the original request never reaches the other client, -the requesting client will again re-issue the request. In either of -these cases the message will be marked with the DB_REP_REREQUEST -flag. The application may continue trying to find another client to -service the request, or it may give up and simply send it to the master -(that is, the environment ID explicitly specified to the transport -function).

- Replication Manager allows an application to designate one or more - remote sites (called its "peers") to receive client-to-client requests. - You do this by setting the DB_REPMGR_PEER parameter - using the DB_SITE->set_config() method. Replication Manager always tries - to send requests marked with the DB_REP_ANYWHERE flag to a peer, if - available. However, it always sends a DB_REP_REREQUEST to the master - site. -

Base API applications have complete freedom -in choosing where to send these DB_REP_ANYWHERE requests, and -in deciding how to handle DB_REP_REREQUEST.

The delayed synchronization and client-to-client synchronization -features allow applications to do load balancing within replication -groups. For example, consider a replication group with 5 sites, A, B, -C, D and E. Site E just crashed, and site A was elected master. Sites -C and D have been configured for delayed synchronization. When site B -is notified that site A is a new master, it immediately synchronizes. -When B finishes synchronizing with the master, the application calls the -DB_ENV->rep_sync() method on sites C and D to cause them to synchronize as well. -Sites C and D (and E, when it has finished rebooting) can send their -requests to site B, and B then bears the brunt of the work and -network traffic for synchronization, making master site A available to -handle the normal application load and any write requests paused by -the election.

+ Furthermore, when the other client receives such a + request it may be unable to satisfy it. In this case it + will reply to the requesting client, telling it that it is + unable to provide the requested information. The + requesting client will then re-issue the request. + Additionally, if the original request never reaches the + other client, the requesting client will again re-issue + the request. In either of these cases the message will be + marked with the DB_REP_REREQUEST flag. The application + may continue trying to find another client to service the + request, or it may give up and simply send it to the + master (that is, the environment ID explicitly specified + to the transport function). +

+ Replication Manager allows an application to designate + one or more remote sites (called its "peers") to receive + client-to-client requests. You do this by setting the + DB_REPMGR_PEER parameter using the + DB_SITE->set_config() method. Replication Manager always + tries to send requests marked with the DB_REP_ANYWHERE + flag to a peer, if available. However, a + DB_REP_REREQUEST message is always handled by requesting + the information from the master. A view can serve as a + peer, but a partial view is more likely to be missing + requested information, which will then be requested from + the master. +

+ Base API applications have complete freedom in choosing + where to send these DB_REP_ANYWHERE requests, and in + deciding how to handle DB_REP_REREQUEST. +

+ The delayed synchronization and client-to-client + synchronization features allow applications to do load + balancing within replication groups. For example, consider + a replication group with 5 sites, A, B, C, D and E. Site E + just crashed, and site A was elected master. Sites C and D + have been configured for delayed synchronization. When + site B is notified that site A is a new master, it + immediately synchronizes. When B finishes synchronizing + with the master, the application calls the DB_ENV->rep_sync() + method on sites C and D to cause them to synchronize as + well. Sites C and D (and E, when it has finished + rebooting) can send their requests to site B, and B then + bears the brunt of the work and network traffic for + synchronization, making master site A available to handle + the normal application load and any write requests paused + by the election. +

Blocked client operations

Clients in the process of synchronizing with the master block access to -Berkeley DB operations during some parts of that process. -By default, most Berkeley DB methods will block until -client synchronization is complete, and then the method call proceeds.

Client applications which cannot wait and would prefer an immediate -error return instead of blocking, should call the -DB_ENV->rep_set_config() method with the DB_REP_CONF_NOWAIT flag. This -configuration causes DB method calls to immediately return a -DB_REP_LOCKOUT error instead of blocking, if the client is -currently synchronizing with the master.

+ Clients in the process of synchronizing with the master + block access to Berkeley DB operations during some parts + of that process. By default, most Berkeley DB methods will + block until client synchronization is complete, and then + the method call proceeds. +

+ Client applications which cannot wait and would prefer + an immediate error return instead of blocking, should call + the DB_ENV->rep_set_config() method with the DB_REP_CONF_NOWAIT flag. + This configuration causes DB method calls to immediately + return a DB_REP_LOCKOUT error instead of blocking, if + the client is currently synchronizing with the + master. +

Clients too far out-of-date to synchronize

Clients attempting to synchronize with the master may discover that -synchronization is not possible because the client no longer has any -overlapping information with the master site. By default, the master and -client automatically detect this state and perform an internal initialization -of the client. Because internal initialization requires transfer of -entire databases to the client, it can take a relatively long period of -time and may require database handles to be reopened in the client -applications.

Client applications which cannot wait or would prefer -to do a hot backup instead of performing internal initialization, should -call the DB_ENV->rep_set_config() method to turn off the DB_REP_CONF_AUTOINIT flag. -Turning off this configuration flag causes Berkeley DB to return -DB_REP_JOIN_FAILURE to the application instead of performing -internal initialization.

+ Clients attempting to synchronize with the master may + discover that synchronization is not possible because the + client no longer has any overlapping information with the + master site. By default, the master and client + automatically detect this state and perform an internal + initialization of the client. Because internal + initialization requires transfer of entire databases to + the client, it can take a relatively long period of time + and may require database handles to be reopened in the + client applications. +

+ Client applications which cannot wait or would prefer to + do a hot backup instead of performing internal + initialization, should call the DB_ENV->rep_set_config() method to turn + off the DB_REP_CONF_AUTOINIT flag. Turning off this + configuration flag causes Berkeley DB to return + DB_REP_JOIN_FAILURE to the application instead of + performing internal initialization. +