Если возникают затруднения, да и вообще для расширения кругозора можно посмотреть на служебные таблицы и их содержимое. Они не видны обычно и находятся в рамках пространства имён _<имя кластера>, например _customers_rep.
Что делать если репликация со временем начинает тормозить
В процессе эксплуатации наблюдаю как со временем растёт нагрузка на master-сервере, в списке активных бекендов постоянные SELECT-ы со слейвов. В pg_stat_activity видим примерно такие запросы:
select ev_origin, ev_seqno, ev_timestamp, ev_minxid, ev_maxxid, ev_xip, ev_type, ev_data1, ev_data2, ev_data3, ev_data4, ev_data5, ev_data6, ev_data7, ev_data8 from "_customers_rep".sl_event e where (e.ev_origin = '2' and e.ev_seqno > '336996') or (e.ev_origin = '3' and e.ev_seqno > '1712871') or (e.ev_origin = '4' and e.ev_seqno > '721285') or (e.ev_origin = '5' and e.ev_seqno > '807715') or (e.ev_origin = '1' and e.ev_seqno > '3544763') or (e.ev_origin = '6' and e.ev_seqno > '2529445') or (e.ev_origin = '7' and e.ev_seqno > '2512532') or (e.ev_origin = '8' and e.ev_seqno > '2500418') or (e.ev_origin = '10' and e.ev_seqno > '1692318') order by e.ev_origin, e.ev_seqno;
Не забываем что _customers_rep имя схемы из примера, у вас будет другое имя.
Таблица sl_event почему-то разрастается со временем, замедляя выполнение этих запросов до неприемлемого времени. Удаляем ненужные записи:
delete from _customers_rep.sl_event where ev_timestamp<NOW()-'1 DAY'::interval;
Производительность должна вернуться к изначальным значениям. Возможно имеет смысл почистить таблицы _customers_rep.sl_log_* где вместо звёздочки подставляются натуральные числа, по-видимому по количеству репликационных сетов, так что _customers_rep.sl_log_1 точно должна существовать.
Londiste
Введение
Londiste представляет собой движок для организации репликации, написанный на языке python. Основные принципы: надежность и простота использования. Из-за этого данное решение имеет меньше функциональности, чем Slony-I. Londiste использует в качестве транспортного механизма очередь PgQ (описание этого более чем интересного проекта остается за рамками данной главы, поскольку он представляет интерес скорее для низкоуровневых программистов баз данных, чем для конечных пользователей администраторов СУБД PostgreSQL). Отличительными особенностями решения являются:
возможность потабличной репликации;
начальное копирование ничего не блокирует;
возможность двухстороннего сравнения таблиц;
простота установки.
К недостаткам можно отнести:
триггерная репликация, что ухудшает производительность базы.
Установка
На серверах, которые мы настраиваем рассматривается ОС Linux, а именно Ubuntu Server. Автор данной книги считает, что под другие операционные системы (кроме Windows) все мало чем будет отличаться, а держать кластера PostgreSQL под ОС Windows, по меньшей мере, неразумно.
Поскольку Londiste это часть Skytools, то нам нужно ставить этот пакет. На таких системах, как Debian или Ubuntu skytools можно найти в репозитории пакетов и поставить одной командой:
% sudo aptitude install skytools
Но в системных пакетах может содержатся версия 2.x, которая не поддерживает каскадную репликацию, отказоустойчивость(failover) и переключение между серверами (switchover). По этой причине я не буду её рассматривать. Скачать самую последнюю версию пакета можно с официального сайта. На момент написания главы последняя версия была 3.2. Итак, начнем:
$ wget http://pgfoundry.org/frs/download.php/3622/skytools-3.2.tar.gz $ tar zxvf skytools-3.2.tar.gz $ cd skytools-3.2/ # пакеты для сборки deb $ sudo aptitude install build-essential autoconf \ automake autotools-dev dh-make \ debhelper devscripts fakeroot xutils lintian pbuilder \ python-all-dev python-support xmlto asciidoc \ libevent-dev libpq-dev libtool # python-psycopg нужен для работы Londiste $
команду drop-node можно удалить slave из кластера:
$ londiste3 /etc/skytools/slave4-londiste.ini drop-node slave4-node $ londiste3 /etc/skytools/slave3-londiste.ini status Queue: replika Local node: slave3-node master-node (root) | Tables: 4/0/0 | Lag: 9s, Tick: 49 +--: slave1-node (leaf) | Tables: 4/0/0 | Lag: 9s, Tick: 49 +--: slave2-node (branch) | Tables: 4/0/0 | Lag: 9s, Tick: 49 +--: slave3-node (branch) Tables: 4/0/0 Lag: 9s, Tick: 49
Команда tag-dead может использоваться, что бы указать slave как не живой (прекратить на него репликацию), а через команду tag-alive его можно вернуть в кластер.
Общие задачи
Проверка состояния слейвов
Этот запрос на мастере дает некоторую информацию о каждой очереди и слейве.
# SELECT queue_name, consumer_name, lag, last_seen FROM pgq.get_consumer_info(); queue_name | consumer_name | lag | last_seen ------------+------------------------+-----------------+----------------- replika | .global_watermark | 00:03:37.108259 | 00:02:33.013915 replika | slave1_l3simple | 00:00:32.631509 | 00:00:32.533911 replika | .slave1-node.watermark | 00:03:37.108259 | 00:03:05.01431
lag столбец показывает отставание от мастера в синхронизации, last\_seen время последней запроса от слейва. Значение этого столбца не должно быть больше, чем 60 секунд для конфигурации по умолчанию.