Software Heritage - Object storage replayer#
Simple command line tool to replicate content objects from a source object
storage to a destination one by listening the content topic of a
swh.journal kafka stream.
This Python module provides a command line tool to replicate content objects from a
source Object storage to a destination one by listening the content topic of a
swh-journal kafka stream.
It is meant to be used as the brick of a mirror setup dedicated to replicating content objects.
Quick start#
Once installed (using pip or debian packages), the command swh objstorage
replay should be available:
It needs a configuration file with 4 sections:
objstorage: the source objstorage to retrieve objects from,objstorage_dst: the destination objstorage to put objects into,journal_client: the journal client (kafka configuration where the object hashes are consumed from),replayer(optional): some replayer specific configurations options.
For example with a configuration file like:
objstorage:
cls: multiplexer
objstorages:
- cls: http
url: https://softwareheritage.s3.amazonaws.com/content/
compression: gzip
- cls: remote
url: https://login:password@objstorage.staging.swh.network
objstorage_dst:
cls: remote
args:
url: http://objstorage:5003
journal_client:
cls: kafka
brokers:
- broker1.journal.staging.swh.network:9093
group_id: kafka-username-content-replayer-003
sasl.username: kafka-username
sasl.password: kafka-password
security.protocol: sasl_ssl
sasl.mechanism: SCRAM-SHA-512
session.timeout.ms: 600000
max.poll.interval.ms: 3600000
message.max.bytes: 1000000000
privileged: true
batch_size: 2000
replayer:
error_reporter:
host: redis
port: 6379
db: 0
you can start the content replayer with:
$ swh objstorage -C replayer-config.yml replay
You would typically run this tool on several machines, using the same
group_id, to increase replication parallelism.
Also note that you may increase the default concurrency within one replayer
using the --concurrency command line option. This will use as many
replication threads as given in argument, distributing the replication of
objects within the same kafka consumer among these threads. This is
typically useful when the replication of one object comes with non negligible
minimal latency (e.g. consuming from public cloud-based objstorages).
Error reporting#
Objects replication may fail. This can happen for several reasons, but we do not want the replication process to stay stuck when this happens in case of a sporadic errors. When this happens, the replication process will log the issue and continue replicating objects.
Errors will be reported in the logging system, however this is not always the best way to keep track of these specific errors.
So there is an error reporting mechanism provided by the replayer, typically using a Redis key/value DB to collect errors.
This is enabled by configuring the replayer/error_reporter section in the
configuration file.
Each time an object failed to be replicated from the source objstorage to the destination one, the event will be logged in Redis using the following format:
the key is formatted like
<timestamp>/blobwheretimestampis the timestamp, as an ISO date format, when the failure occurredexample:
2025-10-28T11:27:53.754796+00:00/blob
the value will be a yaml-encoded dictionary with 4 keys:
obj_id: the object keys as a dict of hashes,operation: the name of the function that failed (get_objectorput_object)retries: number of retries has been attemptedexc: a list of strings representing the exception at the root of the failure, if any (None otherwise),
Legacy error reporting formats#
Other error reporting formats have been in use in previous versions of the
swh-objstorage-replayer package, so you may find these formats in an
existing Redis database.
For swh-objstorage-replayer < 2.2 the format was:
the key is formatted like
blob:<hashes>wherehashesis the identifier of the object as the list of{hash_algo}:{hash}of the object separated by semicolons like:blob:blake2s256:d07c3a320456a17bddc0cf064f1bbebed3962c41c73c2667f41c26348278f9e0;\ sha1:7202f5783c1addfec40f9ec097594200f451bb62;sha1_git:b833f53158793137e81deb5d6d53b9353d0c7393;\ sha256:78554ca0f037f431117359a83b58dbb1479eb68b019a22aa75ff4e282256261c
the value is the same dict structure as above but
msgpackserialized and with: -obj_id: the object hashes formatted the same as the key
For swh-objstorage-replayer < 2.0:
the key only contains the
sha1of the object, like:blob:7202f5783c1addfec40f9ec097594200f451bb62
the value is the same dict structure as above but
msgpackserialized and with: -obj_id: the sha1 of the object (hex form)