Речь пойдет преимущественно про master-slave репликацию

Основные ее задачи (1) иметь возможность восстановиться после падения, (2) разгрузить основную БД с чтения

Топлогия – это связи этих master-slave узлов базы (представьте себе граф / дерево это и будет топология)

У репликации среднестатистически есть 2 уровня надежности: async и sync

Проблема sync в том, что БД будет задерживать подтверждение транзакции, пока не подтвердит реплика, проблема async, что при падении мастера часть транзакций будет отсутствовать в реплике, но при этом нет задержки на подтверждение транзакций

“Средняя по больнице” топология это когда у вас 1 master и 2 slave на async репликации в разных датацентрах

Так вот, по факту, мы можем делать топологию, в которой первые 1-2 ноды в sync, но находятся близко к мастер базе (в рамках как минимум одного датацентра), а потом 1-n нод в async

С одной стороны, у нас есть надежная sync репликация с наименьшей задержкой, потому что реплики лежат максимально близко к мастеру, с другой есть async реплики, которые можно положить достаточно далеко для надежности, но данные в них понадобятся только для чтения не в realtime

Не могу сказать, что советую всем и сразу, скорее, надо иметь ввиду такую возможность

Видео по теме

как раз тут CockroachDB анонсировали интересную новую систему реплицирования данных MOLT Live Migration Service

Инструмент по миграции со старых систем на CDB… Вау, ну ребята реально понимают что нужно бизнесу