The pool names in both clusters have to be identical in addition to the required journal feature. It’s probably an advantage if the existing pool in the second cluster has a different name. In that case you can set up the mirror for a new pool without affecting the other pool and after mirroring has completed move the images into the destination pool. Zitat von Zhenshi Zhou <deaderzzs@gmail.com>:

As a matter of my experience, rbd-mirror only copy the images with journaling feature of clusterA to clusterB. It doesn't influence the other images in the pool of clusterB. You'd better have a test on it.

Kees Meijs | Nefos <kees@nefos.nl> 于2020年5月14日周四 下午10:22写道：

...

Hi list,

Thanks again for pointing me towards rbd-mirror!

I've read documentation, old mailing list posts, blog posts and some additional guides. Seems like the tool to help me through my data migration.

Given one-way synchronisation and image-based (so, not pool based) configuration, it's still unclear to me how the mirroring will cope with an existing target pool, already consisting of (a lot of) images.

Has someone done this already? It feels quite scary with doom scenario's like "cleaning up" the target pool and such in mind...

To sum up: my goal is to mirror clusterA/somepool with some specific images to clusterB/someotherpool where already other images reside. The mirrored images should be kept in sync and the other images should be left alone completely.

Cheers, Kees

-- https://nefos.nl/contact

Nefos IT bv Ambachtsweg 25 (industrienummer 4217) 5627 BZ Eindhoven Nederland

KvK 66494931

/Aanwezig op maandag, dinsdag, woensdag en vrijdag/ _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io

_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io

-- Eugen Block voice : +49 40 5595175 NDE Netzdesign und -entwicklung AG fax : +49 40 5595177 Postfach 61 03 15 e-mail : username@nde.ag D-22423 Hamburg Vertretungsberechtigter Vorstand: Jens-U. Mozdzen Vorsitzende des Aufsichtsrats: Angelika Torlée-Mozdzen Sitz und Registergericht: Hamburg, HRB 90934 USt-IdNr: DE 814 013 983

Hi Anthony, A one-way mirror suits fine in my case (the old cluster will be dismantled in mean time) so I guess a single rbd-mirror daemon should suffice. The pool consists of OpenStack Cinder volumes containing a UUID (i.e. volume-ca69183a-9601-11ea-8e82-63973ea94e82 and such). The change of conflicts is near to zero. My main concern is pulling images into a non-empty pool. It would be (very) bad if rbd-mirror tries to be smart and removes images that don't exist in the source pool. Regards and thanks again, Kees On 14-05-2020 17:41, Anthony D'Atri wrote:

When you set up the rbd-mirror daemons with each others’ configs, and initiate mirroring of a volume, the destination will create the volume in the destination cluster and pull over data.

Hopefully you’re creating unique volume names so there won’t be conflicts, but that said if the destination has a collision, it won’t be overwritten.

Thanks for clearing that up, Jason. K. On 14-05-2020 20:11, Jason Dillaman wrote:

rbd-mirror can only remove images that (1) have mirroring enabled and (2) are not split-brained with its peer. It's totally fine to only mirror a subset of images within a pool and it's fine to only mirror one-way.