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