From 72f2276c1a5f175ff65c206c67c3782aca63080e Mon Sep 17 00:00:00 2001 From: Chris Lu Date: Sun, 7 Nov 2021 14:49:18 -0800 Subject: [PATCH] Updated Filer Store Replication (markdown) --- Filer-Store-Replication.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Filer-Store-Replication.md b/Filer-Store-Replication.md index dd19e32..1bfe351 100644 --- a/Filer-Store-Replication.md +++ b/Filer-Store-Replication.md @@ -34,7 +34,9 @@ So aggregating metadata updates form its peers is required when the filers are u If the filer is running on embedded store, the metadata updates from its peers would be saved locally. -This basically synchronize the metadata across all the filer stores. If filers are using shared filer stores, this is optional. +This basically synchronize the metadata across all the filer stores, where every filer store will have a full copy of all the metadata. + +This also naturally replicated the filer store to achieve high availability for metadata. # Example Topologies @@ -57,7 +59,7 @@ filer1(leveldb) <-> filer2(leveldb) filer1(leveldb) <-> filer2(rocksdb) ``` -* Two filers with one shared stores are fine. +* Two filers with one shared store instance are fine. ``` filer1(mysql) <-> filer2(mysql) @@ -65,6 +67,7 @@ filer1(mysql) <-> filer2(mysql) * Two filers with a shared store and an embedded store are NOT fine. +This is because the `filer2` here will not attempt to persist `filer1` metadata updates to its mysql store. ``` filer1(leveldb) <--XX NOT WORKING XX---> filer2(mysql) ```