# Репликаиция Виды реплицкации ### Потоковая репликация(Streaming Replication) Это репликация, при которой от основного сервера PostgreSQL на реплики передается WAL. И каждая реплика затем по этому журналу изменяет свои данные. Для настройки такой репликации все серверы должны быть одной версии, работать на одной ОС и архитектуре. Потоковая репликация в Postgres бывает двух видов — асинхронная и синхронная. + Работает из коробки. Годами обкатанная технология + Низкое потребление ресурсов, так как никакой логики при репликации нет, изменения выполняются в том же порядке, что и на мастере + Простота конфигурации, настроил и забыл, простое побайтовое копирование через WAL - Реплицируется весь кластер целиком - Реплицируются все операции, включая ошибки - Изменения применяются в один поток - Работа только в рамках одной мажорной версии - Слейвы геаd оп!у ### Логическая репликация (Logical Replication) Этот вид репликации построен на механизме публикации/подписки: один сервер публикует изменения, другой подписывается на них. При этом подписываться можно не на все изменения, а выборочно. Например, на основном сервере 50 таблиц: 25 из них могут копироваться на одну реплику, а 25 — на другую. Также есть несколько ограничений, главное из которых — нельзя реплицировать изменения структуры БД. То есть если на основном сервере добавится новая таблица или столбец — эти изменения не попадут в реплики автоматически, их нужно применять отдельно. Логическая репликация оперирует записями в таблицах PostgreSQL. Этим она отличается от потоковой репликации, которая оперирует физическим уровнем данных: биты, байты, и адреса блоков на диске. + Тоже основана на WAL + Мастер и слейв могут иметь разные представления данных на диске, разные архитектуры процессора, разные структуры таблиц (при условии совместимости схем), разные конфигурации и расположение файлов данных + Частичная репликация, можно реплицировать только необходимые данные - Необходимо повысить уровень логирования, гораздо больше информации необходимо писать в транзакционный лог - Только DML - Нельзя менять объекты (схему, название) - Работает только с версии Postgres 10+ ### Синхронная В этом случае изменения сначала записываются в WAL хотя бы одной реплики и только после этого фиксируются на основном сервере. Преимущество — более надежный способ, при котором сложнее потерять данные. Недостаток — операции выполняются медленнее, потому что прежде чем подтвердить транзакцию, нужно сначала продублировать ее на реплике. ### Асинхронная В этом случае PostgreSQL сначала применит изменения на основном узле и только потом отправит записи из WAL на реплики. Преимущество такого способа — быстрое подтверждение транзакции, т.к. не нужно ждать пока все реплики применят изменения. Недостаток в том, что при падении основного сервера часть данных на репликах может потеряться, так как изменения не успели продублироваться. ### Идеальный набор 1. Master 2. Асинхронная реплика 3. Асинхронная реплика 4. Асинхронная реплика 5. Синхронная реплика # Портиционирование Что такое партиционирование и как это работает? ### Проблемы больших таблиц * На каждый insert/update перестраиваем индексы, чем больше таблица, тем дороже перестройка индекса * Если много удаляем/апдейтим записи в базе, то vacuum может быть проблемой, update=delete+insert * Селекты делать только по индексам, чем больше индексов, тем больнее каждый insert/update ### Что такое партиционирование и как это работает? * Очень внимательно относиться к количеству партиций, идеально не больше 100-200 * Не нагружать БД проверками, которые можем сделать на клиентах » Не использовать встроенные системы автовычисления партиций на БД * Не использовать триггеры для автоматического создания партиций # Шардирование Шардинг — это процесс разделения одного большого, структурированного, непрерывного набора некоторых объектов (я не называю их строками, поскольку мы можем шардировать любой набор данных, вне зависимости от метода их хранения) на более мелкие части с одинаковой структурой и размещения этих частичных наборов на разных физических серверах. ### Проблемы, которые возникают после шардирования * Система кратно усложняется в обслуживании, вместо 1 сервера у вас становится много точек отказа * Нужно заранее продумать логику будущего решардинга, даже если сейчас вам кажется, что шардов вам хватит * Нужно оборачивать запросы в доп логику, высчитывать нужный шард, держать множество коннектов