Как настроить репликацию Master Slave на PostgreSQL на Ubuntu 12.04 VPS
Статус: устарело
В этой статье рассматривается версия Ubuntu, которая больше не поддерживается. Если вы в настоящее время используете сервер под управлением Ubuntu 12.04, мы настоятельно рекомендуем обновить или перейти на поддерживаемую версию Ubuntu:
- Обновите Ubuntu до версии 14.04.
- Обновление Ubuntu 14.04 до Ubuntu 16.04
- Перенесите данные сервера в поддерживаемую версию.
Причина:
Смотрите вместо этого:
Введение
PostreSQL или postgres — это популярная система управления базами данных, которая может организовывать и управлять данными, связанными с веб-сайтами или приложениями. Репликация — это средство копирования информации из базы данных во вторую систему для обеспечения высокой доступности и избыточности.
Существует много способов настроить репликацию в системе postgres. В этом руководстве мы расскажем, как настроить репликацию с использованием горячего резерва, преимуществом которого является относительно простая настройка.
Для этого нам понадобятся два экземпляра Ubuntu 12.04 VPS. Один будет служить главным сервером базы данных, а другой — подчиненным, который будет реплицироваться.
Установите программное обеспечение PostgreSQL
Действия, описанные в этом разделе, следует выполнять как на главном, так и на подчиненном серверах.
Программное обеспечение postgres доступно в стандартных репозиториях Ubuntu. Установите соответствующие пакеты с помощью этих команд.
sudo apt-get update
sudo apt-get install postgresql postgresql-contrib postgresql-client
PostgreSQL создает пользователя с именем «postgres» для обработки своих исходных баз данных. Мы настроим доступ ssh между нашими серверами, чтобы упростить передачу файлов.
Нам нужно будет установить пароль для пользователя postgres, чтобы мы могли изначально передавать файлы ключей. При желании вы можете удалить пароль позже:
sudo passwd postgres
Переключитесь на пользователя postgres следующим образом:
sudo su - postgres
Сгенерируйте ssh-ключ для пользователя postgres:
ssh-keygen
Нажмите \ENTER для всех последующих подсказок.
Перенесите ключи на другой сервер, набрав:
<пред>
Теперь вы должны иметь возможность свободно подключаться по ssh между двумя вашими серверами как пользователь postgres.
Настройте главный сервер
Мы начнем с настройки нашего главного сервера. Все эти команды должны выполняться пользователем postgres.
Во-первых, мы создадим пользователя с именем \rep, который можно использовать исключительно для репликации:
<пред>
Измените пароль на любой, который вы хотите использовать.
Далее мы перейдем в каталог конфигурации postgres:
cd /etc/postgresql/9.1/main
Мы изменим файл доступа с помощью только что созданного пользователя:
nano pg_hba.conf
В любом месте, не в самом низу файла, добавьте строку, позволяющую новому пользователю получить доступ к этому серверу:
<пред>
Сохраните и закройте файл.
Далее мы откроем основной файл конфигурации postgres:
nano postgresql.conf
Найдите эти параметры. Раскомментируйте их, если они закомментированы, и измените значения в соответствии с тем, что мы перечислили ниже:
<пред>
Сохраните и закройте файл.
Перезапустите главный сервер, чтобы изменения вступили в силу:
service postgresql restart
Настройте подчиненный сервер
Начните на подчиненном сервере, выключив программное обеспечение базы данных postgres:
service postgresql stop
Мы будем вносить аналогичные изменения в файлы postgres, поэтому перейдите в каталог конфигурации:
cd /etc/postgresql/9.1/main
Настройте файл доступа, чтобы разрешить другому серверу подключаться к нему. Это на случай, если позже нам понадобится превратить раба в мастера.
nano pg_hba.conf
Снова добавьте эту строку где-нибудь не в конец файла:
<пред>
Сохраните и закройте файл.
Затем откройте файл конфигурации postgres:
nano postgresql.conf
Вы можете использовать те же параметры конфигурации, которые вы установили для главного сервера, изменив только IP-адрес, чтобы отразить адрес подчиненного сервера:
<пред>
Сохраните и закройте файл.
Репликация исходной базы данных:
Прежде чем ведомое устройство сможет реплицировать ведущее, нам нужно предоставить ему исходную базу данных для построения. Это связано с тем, что он считывает журналы с главного сервера и применяет изменения к своей собственной базе данных. Нам нужно, чтобы эта база данных соответствовала основной базе данных.
На главном сервере мы можем использовать внутреннюю команду запуска резервного копирования postgres для создания команды метки резервного копирования. Затем мы перенесем данные базы данных на наше ведомое устройство, а затем выполним внутреннюю команду остановки резервного копирования для очистки:
<пред>
Команда rsync могла иметь ошибку при изменении файлов сертификатов, но это нормально для нашего использования. Данные мастера теперь должны быть на ведомом.
Теперь нам нужно настроить файл восстановления на нашем ведомом устройстве. На подчиненном устройстве перейдите в каталог данных:
cd /var/lib/postgresql/9.1/main
Здесь нам нужно создать файл восстановления с именем recovery.conf:
nano recovery.conf
Заполните следующую информацию. Обязательно измените IP-адрес вашего главного сервера и пароль для пользователя rep, которого вы создали:
<пред>
Последняя строка в файле, trigger_file, является одной из самых интересных частей всей конфигурации. Если вы создадите файл в этом месте на своей подчиненной машине, ваша подчиненная система перенастроит себя, чтобы действовать как главная.
Это нарушит вашу текущую репликацию, особенно если главный сервер все еще работает, но это то, что вам нужно будет сделать, если ваш главный сервер выйдет из строя. Это позволит подчиненному устройству начать принимать записи. Затем вы можете починить главный сервер и превратить его в подчиненный.
Теперь у вас должны быть готовые компоненты для запуска подчиненного сервера. Тип:
service postgresql start
Вы захотите проверить журналы, чтобы увидеть, есть ли какие-либо проблемы. Они расположены на обеих машинах здесь:
less /var/log/postgresql/postgresql-9.1-main.log
Вы должны увидеть, что он успешно подключается к главному серверу.
Протестируйте репликацию
Мы из первых рук увидим, правильно ли реплицируются наши серверы, внеся некоторые изменения на главном сервере, а затем запросив подчиненный.
На главном сервере, как пользователь postgres, войдите в систему postgres, набрав:
psql
Ваше приглашение изменится, показывая, что вы сейчас взаимодействуете с программным обеспечением базы данных.
Мы создадим тестовую таблицу, чтобы внести некоторые изменения:
CREATE TABLE rep_test (test varchar(40));
Теперь мы можем вставить некоторые значения в таблицу с помощью следующих команд:
INSERT INTO rep_test VALUES ('data one');
INSERT INTO rep_test VALUES ('some more words');
INSERT INTO rep_test VALUES ('lalala');
INSERT INTO rep_test VALUES ('hello there');
INSERT INTO rep_test VALUES ('blahblah');
Теперь вы можете выйти из этого интерфейса, набрав:
\q
Теперь на ведомом входим в интерфейс БД таким же образом:
psql
Теперь мы можем увидеть, были ли данные, которые мы ввели в основную базу данных, были реплицированы на ведомом устройстве:
SELECT * FROM rep_test;
test
-----------------
data one
some more words
lalala
hello there
blahblah
(5 rows)
Отличный! Наши данные были записаны как на главный, так и на подчиненный серверы.
Давайте посмотрим, сможем ли мы вставить больше данных в таблицу на нашем подчиненном устройстве:
INSERT INTO rep_test VALUES ('oops');
ERROR: cannot execute INSERT in a read-only transaction
Как видите, мы не можем вставить данные в слейв. Это связано с тем, что данные передаются только в одном направлении. Чтобы поддерживать согласованность баз данных, postgres должен сделать ведомое устройство доступным только для чтения.
Заключение
Теперь у вас должен быть главный и подчиненный серверы PostgreSQL, настроенные для эффективной связи. Если у вас есть приложение, которое будет записывать в базы данных и запрашивать их, вы можете настроить схему балансировки нагрузки, чтобы всегда писать на ведущее устройство, но разделить чтение между ведущим и ведомым. Это может повысить производительность ваших взаимодействий с базой данных.