#ФедиЧитальня #PostgreSQL15 не совсем из книги, но по той же теме.

Глянул кусочек highload.guide, выцепил хорошую выжимку про классификацию репликаций:

- логическая - работает с кортежами; пример - row based binary log в MySQL; бутылочное горлышко - процессор slave.
- физическая - работает со страницами; примеры - pg_wal, innodb undo-redo; бутылочное горлышко - диск (не совсем понял master'а или slave'а, не совсем понял, а как же буферы; возможно дело в большей степени касается MySQL с несколькими журналами одновременно)
- statement based - сплошная боль, есть места где можно получить неконсистентные данные между master и slave, но в случае условной бигдаты - очень низкие накладные расходы на передачу данных по сети, большой update на всю таблицу прилетит практически одним запросом; разве что выполнять его придётся заново на slave, из-за этого может быть длинный лаг репликации.

Если slave может блокировать удаление журнала master'ом, чтобы догнаться в случае ребута, чем больше отставание, тем больше размер журнала. Если slave вообще не догоняет master в принципе и отставание только нарастает - со временем это закончится забитым дисковым хранилищем.

В PostgreSQL есть Logical Log Streaming Replication, который позволяет не миррорить часть таблиц на slave. Как это применять - я не придумал. В теории можно не хранить на слейвах для актуальных данных архивные данные, что позволит немного сэкономить на дисковом пространстве, особенно если slave'ов много.

P.S:
- Раньше жил в прекрасном мире, где БД находится на том же сервере, где и приложение, ни о какой репликации и не думал.
- Сейчас живу в прекрасном мире, где БД поддерживает отдельная команда, репликация уже готова, хоть и без гарантии синхронных записи на мастер и чтения со слэйва (а я и не против), бери да пользуйся.