As discussed throughout this chapter, there is an interaction between consistency and durability. This interaction results in design decisions that you will have to make when designing your HA application. To further illustrate this interaction, this section provides several use cases as examples of how durability and consistency policies are used to reach application design goals.
Out on the Town is a social networking site about restaurants and artistic events. Restaurant locations and an event calendar are available on the site. Members can submit reviews about restaurants and events, and other members can comment on the reviews. Further, members maintain accounts and profiles.
The site experiences most of its traffic as read-only requests. There is heavy read traffic from users who are browsing the site. In addition, periodic write traffic occurs as reviews and comments are submitted to the site.
Based on the site's usage characteristics, the web developers know that it is critical that the site perform well for read traffic. Listings must be readily available, and the site must be able to adapt to changing read loads. However, the site only needs a low threshold for most reads.
While users should not experience a delay when they access the site, it is okay if read requests do not see the very latest reviews. For this reason, when starting read-only transactions for the purpose of viewing reviews, the application specifies a consistency policy of NoConsistencyRequiredPolicy. This provides the highest possible availability for read requests for the Replica nodes, which is the critical thing for this particular site. (Any other consistency policy might cause the node to delay reads while waiting for the node to meet its consistency policy, which would represent an unacceptable loss of availability as it could cost the site lost readership.)
Most write operations are for new user reviews, and for comments on those reviews. For these writes, the application needs only a very lenient durability policy. It is not critical that a new review is immediately available to other users, nor is it critical that they are saved in the event of a catastrophic failure.
Therefore, the application uses the convenience constant Durability.COMMIT_WRITE_NO_SYNC as the system default durability policy. (This is done by specifying the durability policy using EnvironmentMutableConfig.setDurability().) This means:
Write operations on the Master use Durability.SyncPolicy.WRITE_NO_SYNC.
When the write operation is forwarded by the Master to the Replicas, those Replicas use Durability.SyncPolicy.NO_SYNC when they internally update their own databases.
Only a simple majority of the Electable nodes need to acknowledge the update.
Periodically, the calendar of events and restaurant locations are updated. These write operations happen fairly infrequently relative to reviews and comments, but the site's operators deem this information to be of more importance (or valuable) than the reviews and comments. Therefore, they want a stronger guarantee that the information is backed up to all nodes, which is the same thing as saying they want a stronger durability guarantee. Nevertheless, they also want this class of writes to consume few resources.
To achieve this, for transactions performing these kind of writes, the web engineers choose to override the site's default durability guarantee. Instead, they use a durability guarantee that:
Uses Durability.SyncPolicy.SYNC for the local synchronization policy. This ensures that the write is fully backed up to the Master's local disk before the transaction commit operation returns.
Uses Durability.SyncPolicy.WRITE_NO_SYNC for the synchronization policy on the Replica nodes. This causes the updates to be written to the disk controller's buffers, but they are not flushed to disk before the Electable Replicas acknowledge the commit operation.
Stays with a simply majority for acknowledgements, which is the same as is used for the default durability policy.
That is, for updating events and restaurant locations, the application uses this durability policy:
useForUpdates =
new Durability(Durability.SyncPolicy.SYNC,
Durability.SyncPolicy.WRITE_NO_SYNC,
Durability.ReplicaAckPolicy.SIMPLE_MAJORITY);
If a user makes an account profile change as part of a web session, she will naturally expect to see her changes when she next looks at the profile during the same session. From the user's perspective, this is all one operation: she causes her profile to change and then the profile page is refreshed with her new information.
However, from the application's perspective, there are several things going on:
A write transaction is performed on the Master.
One or more read transactions are performed on the Replica node in use by the user as she updates her profile and then reads back the changes she just made.
To ensure that the session interaction looks intuitively consistent to the user, the application:
Performs the write transaction on the Master.
Saves the CommitToken for the account profile update within the web session.
The Replica node uses a CommitPointConsistencyPolicy policy for the follow-on account profile read(s). To do this, the application uses the CommitToken stored in the previous step when beginning the read transactions. In this way, the Replica will not serve up the new profile page until it has received the profile updates from the Master. From the user's perspective, there may be a delay in her page refresh when she submits her updates. How long of a delay experienced by the user is a function of how busy the site is with write updates, as well as the performance characteristics of the hardware and networks in use by the site.
Bio Labs, Inc is a biotech company that is doing pharmaceutical production which must be audited by government agencies. Production sampling results are logged frequently. All such updates must be guaranteed to be backed up. (In other words, this application requires a very high durability guarantee.)
In addition, there are frequent application defined sample points that represent phases in the production cycle. The application performs monitoring of the production stream. These reads are time critical, so the data must be no older than a specific point in time.
Due to the auditing requirement for the sampling results, the application developers want an extremely high data durability guarantee. Therefore, they require the synchronization policy on both the Master and all Electable Replica nodes to be Durability.SyncPolicy.SYNC, which means that the logging data is guaranteed to be written to stable storage before the host returns from its transaction commit.
For an acknowledgement policy, the engineers considered requiring all Electable nodes to acknowledge the commit. This would provide them with the strongest possible durability guarantee. However, they decided against this because it represents a possible loss of write availability for the application; if even one Electable node is shutdown or hidden by a network outage, then the Master would not be able to perform any write operations at all. So instead, the engineers stick with the default acknowledgement policy, which is to require a simple majority of the Electable nodes to acknowledge the commit.
The durability policy, then, looks like this:
resultsDurability =
new Durability(Durability.SyncPolicy.SYNC,
Durability.SyncPolicy.SYNC,
Durability.ReplicaAckPolicy.SIMPLE_MAJORITY);
The BioLabs application is required to monitor the production stream. All such monitoring must be of data that is no older than a defined age.
This represents a read activity that has a time concurrency policy requirement. Therefore, whenever the application performs a write (that is, logs sampling results), the application creates a CommitToken. Each of the nodes, then, use this commit token to specify a CommitPointConsistencyPolicy policy when the Environment.beginTransaction() method is called. This guarantees that the application's data monitoring activities will be performed on data that is not out of date or stale.