В вашем случае потоковая репликация - это то место, с которого нужно начинать.Он не очень гибкий, но он делает то, что вам нужно для чтения базы данных, если вам не нужно выполнять репликацию между основными версиями.
Репликация базы данных 101
База данныхРепликация - это способ обеспечить сохранение данных, сохраненных на определенном сервере, на нескольких других серверах.Это часто делается для того, чтобы лучше использовать более ограниченные сетевые соединения, обеспечить отказоустойчивость (поэтому, по сути, существует горячая резервная копия), гарантировать, что запросы только для чтения могут быть распределены по большому количеству баз данных и т. Д. Все это должно быть сделаноне жертвуя основными гарантиями ACID.
Существует несколько различных перекрывающихся способов классификации решений для репликации.К ним относятся:
В общем, понимание репликации и компромиссов между решениями требует относительно глубокого понимания механики базы данных и гарантий ACID.Я предполагаю, что вы относительно знакомы с механикой хранения, детерминированными и недетерминированными операциями и т. П.
Что такое реплицируемый?Изменения файлов (физические) и изменения строк (логические) и операторы
Самый простой подход состоит в том, чтобы реплицировать изменения блоков в файлы, например, как они хранятся в журнале упреждающей записи в PostgreSQL.Это копирует изменения на уровне страницы и требует идентичных форматов файлов.Это означает, что вы не можете выполнять репликацию между основными версиями, архитектурами ЦП или операционными системами.Например, все, что может повлиять на выравнивание кортежей, приведет к сбою репликации или, что еще хуже, к повреждению базы данных ведомого.Этот подход использует потоковая репликация.Его легко настроить, и он всегда реплицирует все в кластере баз данных.
Кроме того, этот подход означает, что вы можете легко гарантировать, что база данных master и slave идентична вплоть до уровня файлов.Из-за того, что WAL PostgreSQL является кластерно-глобальным, маловероятно, что этот подход когда-либо будет реплицировать что-либо, кроме всего кластера базы данных.
В качестве описания того, как это работает, предположим, что я:
UPDATE my_table SET rand_value = random() WHERE id > 10000;
В этом случае это приводит к изменению группы страниц данных, и файловые операции реплицируются на реплики.Файлы остаются одинаковыми для главного и подчиненного.
Другой подход, который используют Слони, Букардо и другие, состоит в том, чтобы копировать строки логическим способом.При таком подходе измененные строки помечаются и регистрируются, а изменения отправляются в реплики.Реплики повторно запускают операций с строками из базы данных master.Поскольку это дополнительные инструменты, которые не реплицируют файловые операции, а скорее логические операции с базой данных, они могут реплицироваться в архитектурах ЦП, операционных системах и т. Д. Кроме того, они обычно разрабатываются так, что вы можете реплицировать некоторые, но не все таблицы в базе данных,учитывая большую гибкость.С другой стороны, это приводит к большой вероятности ошибок.«К сожалению, эта таблица не была реплицирована» - это реальная проблема.
В этом случае, когда я запускаю приведенный выше оператор обновления, запускается триггер, фиксирующий фактические вставленные и удаленные строки, которые регистрируются, реплицируются иперезапуск строкПоскольку это происходит после запуска rand (), базы данных логически, но не обязательно физически идентичны.
Последний подход - репликация операторов. В этом случае мы реплицируем операторы и повторно запускаем операторы на репликах. Некоторые конфигурации PgPool будут делать это. В этом случае вы не можете гарантировать, что база данных логически эквивалентна ее реплике, если запущены какие-либо недетерминированные функции. В приведенном выше утверждении само утверждение будет выполняться для каждой реплики, обеспечивая различных псевдослучайных чисел в соответствующем столбце.
Синхронный и Асинхронный
Это различие важно понимать в отношении гарантий отработки отказа. В системе асинхронной репликации обновления ставятся в очередь и по возможности передаются в реплики и повторно запускаются там. В системе синхронной репликации база данных, которая принимает запись , не будет возвращать успешную фиксацию, пока по крайней мере определенное количество баз данных реплики не сообщит об успешной фиксации.
Асинхронная репликация, как правило, более устойчива и обеспечивает лучшую доступность, чем синхронная репликация. Это связано с тем, что синхронная репликация создает дополнительные точки отказа. Если у вас есть один ведущий и один ведомый, то если система или выйдет из строя, ваша база данных станет недоступной по крайней мере для операций записи.
Однако компромисс заключается в том, что синхронная репликация обеспечивает гарантию того, что данные, которые были зафиксированы, фактически доступны на репликах в случае, если, скажем, мастер страдает от катастрофического аппаратного сбоя сразу после принятия. Это событие с очень низкой вероятностью, но в некоторых случаях важно, чтобы вы знали, что данные все еще доступны. Вкратце, это обеспечивает дополнительные гарантии долговечности, которых нет в асинхронной репликации.
Multi-Master vs Master-Slave
Большинство систем репликации являются подчиненными. В этом случае все записи начинаются с одного узла и реплицируются на другие узлы. Запись может начинаться только с одного узла. Они могут не начинаться в других узлах. Это упрощает репликацию, поскольку мы знаем, что ведомые устройства представляют прошлое состояние мастера.
Репликация с несколькими хозяевами позволяет выполнять запись более чем на один узел. В асинхронной системе репликации это приводит к проблеме разрешения конфликтов. Эти проблемы на самом деле хуже, чем многие предполагают при добавлении операторов DDL. Предположим, что два разных пользователя запускают приведенный выше оператор обновления на двух разных мастерах. Теперь у нас будет набор записей, которые необходимо реплицировать, но они будут конфликтовать.
Для репликации с несколькими мастерами обычно требуется, чтобы люди тщательно продумали процесс разрешения конфликта. Это никогда не процесс, который просто работает из коробки. Часто вы пишете свои собственные процедуры разрешения конфликтов. По этой причине я обычно рекомендую избегать многоузловой репликации, если она вам действительно не нужна.