Using the Master/Slave Datastore
The Master/Slave Datastore is a deprecated data storage option formerly offered by Google App Engine, in which a single data center is designated to hold the master copy of all data. Data written to the master data center is replicated asynchronously to all other (slave) data centers. Since only one data center is the master for writing at any given time, this option offers strong consistency for all reads and queries, at the cost of periods of temporary unavailability during data center issues or planned downtime.
As of April 4, 2012, the Master/Slave Datastore has been deprecated in favor
of the
High Replication Datastore (HRD),
in which data is
replicated across multiple datacenters using a system based on the
Paxos algorithm
.
Although Google will continue to support the Master/Slave Datastore in
accordance with our
terms of service
,
it is strongly recommended that all new applications use the HRD instead, and
that existing applications using the Master/Slave Datastore
migrate to the HRD
.
This page describes differences between the two for the benefit of legacy
applications still using the Master/Slave Datastore.
Watch a video demonstration comparing the Master/Slave and High
Replication Datastores.
The Master/Slave Datastore is suitable only for a limited class of applications that
- do not require high availability of data
- can tolerate spikes in Datastore latency
The following table summarizes the differences between the Master/Slave Datastore and the High Replication Datastore (HRD):
| High Replication | Master/Slave | |
|---|---|---|
| Put/delete latency | 1/2x–1x | 1x |
| Get latency | 1x | 1x |
| Query latency | 1x | 1x |
| Put/get/delete consistency | Strong | Strong |
| Most queries consistency | Eventual | Strong |
| Ancestor queries consistency | Strong | Strong |
| Occasional planned read-only period | No | Yes |
| Unplanned downtime | Extremely rare; no data loss | Rare; possible to lose a small % of writes occurring near downtime |
In addition, the Master/Slave Datastore differs from the HRD in the following ways:
- Storage resource costs are the same for both options, but only paid applications using the HRD are covered by the App Engine Service Level Agreement (SLA) .
- Unlike the HRD, the Master/Slave Datastore does not support cross-group transactions spanning multiple entity groups ; all entities retrieved, created, updated, or deleted in a transaction must be in the same entity group.
- As described on the Datastore Overview page, Datastore writes that have been committed but not yet applied are automatically rolled forward to completion when certain operations (get, put, delete, and ancestor queries) are performed on entities in the affected entity group. In the Master/Slave Datastore, ancestor queries trigger such an automatic Apply only when they are included within a transaction.
- In the HRD, as long as a few hundred milliseconds may elapse from the time a write operation returns until the transaction is completely applied. In this case, queries spanning more than one entity group cannot determine whether there are any outstanding modifications before executing and may return stale results. This is usually not an issue with the Master/Slave Datastore, because the entire transaction is normally completed before the operation returns.