ZODB Replicated Storage

ZODB replicated storage (ZRS) provides database replication for
ZODB. For each database, a primary storage and one or more secondary
storages may be defined. The secondary storages will automatically
replicate data from the primary storage.

Replication is superior to back-ups because as long as secondaries are
running, secondary data is kept updated. In the event of a failure of
a primary storage, just reconfigure a secondary to be the primary, and
it can begin handling application requests.

If using an application, like a ZEO server or Zope, that uses ZConfig to configure ZODB storages,
the configuration of a ZRS primary or secondary storage may be
included in the configuration file as with any other storage e.g, to
configure a primary storage, use something like:

The import statement is necessary to load the ZConfig schema
definitions for ZRS.

<zrs>

The zrs section defines a ZRS storage. A ZRS storage may be a primary
storage or a secondary storage. A ZRS storage without a
replicate-from option (as in the example above) is a primary
storage.

replicate-to 5000

The replicate-to option specifies the replication address. Secondary
storages will connect to this address to download replication
data. This address can be a port number or a host name (interface
name) and port number separated by a colon.

<filestorage>
path /path/to/data/file
</filestorage>

A ZRS storage section must include a filestorage section specifying a
file storage to contain the data.

Configuring a secondary storage is similar to configuring a primary
storage:

For a secondary storage, a replicate-from option is used to specify
the address to replicate data from.

Because primary and secondary storages are generally on separate
machines, the host is usually specified in a replicate-from
option.

A secondary storage can also specify a replicate-to option. If this
option is used, other secondary storages can then replicate from the
secondary, rather than replicating from the primary.

Secondary storages also support the following optional option:

keep-alive-delay SECONDS

In some network configurations, TCP connections are broken after
extended periods of inactivity. This may even be done in a way that
a client doesn't detect the disconnection. To prevent this, you can
use the keep-alive-delay option to cause the secondary storage
to send periodic no-operation messages to the server.

Primaries and secondaries can register with ZooKeeper, so Secondaries
can find primaries to replicate from without needing to configure a
specific address. See zk.test and zkconfig.test in the source
directory for more details.