Evolution of Geo-replication in Gluster
summary
Geo-replication provides disaster recovery by copying a Gluster master volume to one or more remote slave volumes using SSH plus rsync/tar; it implements three sync modes — an initial hybrid crawl to create virtual changelogs, ongoing changelog crawl, and changelog-replay for large backlogs. The pipeline is translator→flatfile changelog→agent→worker (copies) watched by a monitor. A new path-based geo-replication replaces GFID with parent xattrs so targets need not be Gluster volumes. Demo shows a working master→slave sync (10 files), typical configs use up to ~3 slaves.
AI-written summary · about
chapters (9)
- 0:00Introduction to Gluster
- 2:26Geo-replication need and principles
- 5:53Three sync modes in geo-replication
- 8:00Geo-replication internal components
- 10:27GFID limits and path-based geo-replication
- 13:45Geo-replication setup demo
- 18:47Scalability and slave replica management
- 20:52Retry on transfer failure
- 23:53Q&A
related talks
18mClient Driven Geo-Redundancy for Ceph Object Storage
53mMulti master replication for painless fault tolerance
44mEasy Geo-Redundancy with MARS
51mGeo-Distributed Postgres Replication Using Debezium
24mAutomatic DDL Replication with pgEdge Distributed Postgres
23mEasy Geo-Redundant Handover + Failover with MARS + systemd
35mKeeping Ceph RGW Object Storage Consistent
24mStronger Semantics for Low-Latency Geo-Replicated Storage