mirror of
https://github.com/zrepl/zrepl.git
synced 2024-11-25 09:54:47 +01:00
30cdc1430e
This commit
- adds a configuration in which no step holds, replication cursors, etc. are created
- removes the send.step_holds.disable_incremental setting
- creates a new config option `replication` for active-side jobs
- adds the replication.protection.{initial,incremental} settings, each
of which can have values
- `guarantee_resumability`
- `guarantee_incremental`
- `guarantee_nothing`
(refer to docs/configuration/replication.rst for semantics)
The `replication` config from an active side is sent to both endpoint.Sender and endpoint.Receiver
for each replication step. Sender and Receiver then act accordingly.
For `guarantee_incremental`, we add the new `tentative-replication-cursor` abstraction.
The necessity for that abstraction is outlined in https://github.com/zrepl/zrepl/issues/340.
fixes https://github.com/zrepl/zrepl/issues/340
48 lines
2.4 KiB
ReStructuredText
48 lines
2.4 KiB
ReStructuredText
.. include:: ../global.rst.inc
|
|
|
|
|
|
Replication Options
|
|
===================
|
|
|
|
|
|
::
|
|
|
|
jobs:
|
|
- type: push
|
|
filesystems: ...
|
|
replication:
|
|
protection:
|
|
initial: guarantee_resumability # guarantee_{resumability,incremental,nothing}
|
|
incremental: guarantee_resumability # guarantee_{resumability,incremental,nothing}
|
|
...
|
|
|
|
.. _replication-option-protection:
|
|
|
|
``protection`` option
|
|
--------------------------
|
|
|
|
The ``protection`` variable controls the degree to which a replicated filesystem is protected from getting out of sync through a zrepl pruner or external tools that destroy snapshots.
|
|
zrepl can guarantee :ref:`resumability <step-holds>` or just :ref:`incremental replication <replication-cursor-and-last-received-hold>`.
|
|
|
|
``guarantee_resumability`` is the **default** value and guarantees that a replication step is always resumable and that incremental replication will always be possible.
|
|
The implementation uses replication cursors, last-received-hold and step holds.
|
|
|
|
``guarantee_incremental`` only guarantees that incremental replication will always be possible.
|
|
If a step ``from -> to`` is interrupted and its `to` snapshot is destroyed, zrepl will remove the half-received ``to``'s resume state and start a new step ``from -> to2``.
|
|
The implementation uses replication cursors, tentative replication cursors and last-received-hold.
|
|
|
|
``guarantee_nothing`` does not make any guarantees with regards to keeping sending and receiving side in sync.
|
|
No bookmarks or holds are created to protect sender and receiver from diverging.
|
|
|
|
**Tradeoffs**
|
|
|
|
Using ``guarantee_incremental`` instead of ``guarantee_resumability`` obviously removes the resumability guarantee.
|
|
This means that replication progress is no longer monotonic which might lead to a replication setup that never makes progress if mid-step interruptions are too frequent (e.g. frequent network outages).
|
|
However, the advantage and :issue:`reason for existence <288>` of the ``incremental`` mode is that it allows the pruner to delete snapshots of interrupted replication steps
|
|
which is useful if replication happens so rarely (or fails so frequently) that the amount of disk space exclusively referenced by the step's snapshots becomes intolerable.
|
|
|
|
.. NOTE::
|
|
|
|
When changing this flag, obsoleted zrepl-managed bookmarks and holds will be destroyed on the next replication step that is attempted for each filesystem.
|
|
|