Данная статья может быть интересна тем, кто уже имеет поверхностное представление о типах и проблемах репликации внутри кластера PostgreSQL, а также тем, кто решит использовать потоковую СУБД PipelineDB в качестве реплики в таком кластере.
PipelineDB — одна из реализаций потоковых СУБД, которые в настоящее время набирают популярность.
О преимуществах потоковой передачи СУБД в различных случаи Сегодня вы можете легко прочитать на многих ресурсах.
Принцип их работы очень просто наглядно представлен на сайте.
www.pipelinedb.com в разделе «Как это работает».
Конкретно PipelineDB — это форк PostgreSQL с дополнительным функционалом, позволяющим хранить только агрегированные данные, вычисляя дельту из входящего потока (отсюда и название этого типа СУБД) на лету.
Эти данные хранятся в специальных объектах PipelineDB, называемых непрерывными представлениями.
Сам поток в простейшем случае формируется из обычных таблиц, хранящихся в одной базе данных.
Использование этого инструмента позволяет нам избавиться от необходимости создавать и поддерживать уровень ETL при подготовке данных для систем отчетности, а также позволяет сэкономить вам массу времени и нервов.
Но я считаю, что раз вы это читаете, значит, вы уже что-то знаете об этом в объеме, достаточном для того, чтобы вызвать интерес к описываемым здесь событиям.
Мы рассмотрим случай, когда у нас уже есть СУБД PostgreSQL версии 9.4+, работающая в производственной среде, и нам необходимо получить ее реплику реального времени (или почти реального времени), чтобы избавить основную базу данных от множества и тяжелые запросы SELECT, полученные, например, от систем отчетности, DWH или наших витрин данных.
И, изучив вопрос, вы можете решить, что потоковая СУБД очень хорошо подходит для этой задачи.
Но вот проблема: какой механизм репликации мне следует использовать? После доп.
изучаю вопрос Мы пришли к выводу, что замечательный встроенный в PostgreSQL механизм потоковой асинхронной (физической) репликации, который появился в PostgreSQL версии 9.0 и постоянно развивается, не подходит из-за своих ограничений, а именно: а) мастер и реплика должны иметь одну и ту же основную версию PostgreSQL и, если возможно, работать на идентичном оборудовании.
б) реплика работает в режиме «горячего резерва», в котором она доступна только для чтения в) при использовании физической репликации мы можем иметь только полную однозначную реплику мастера В моем случае первое ограничение не позволило бы мне поднять реплику главного сервера с Postgre 9.6 на PipelineDB, потому что версия Postgre, от которой «разветвлена» последняя версия PipelineDB, которую я использую, — всего 9.5. Если ваш мастер работает под управлением Postgre 9.5, то можно попробовать этот трюк, но велика вероятность того, что мастер-сервер просто не распознает PipelineDB как полноценный и равноправный PostgreSQL — механизм физической репликации в этом плане очень капризен.
Второе ограничение более существенно.
Как мы уже выяснили, PipelineDB записывает свои данные в базу данных.
Как минимум, это сплошные просмотры, ради чего мы с ним и заморачивались.
Но второе ограничение позволяет нашей реплике быть лишь полной, однозначной, копией базы данных мастера без возможности записи в нее.
Что нас совершенно не устраивает. Таким образом, поскольку физическая репликация нам не подходит, мы понимаем, что нужно смотреть в сторону логической репликации.
Не без своих недостатков, но полностью устраняющих эти два ограничения, а именно: а) логическая репликация позволяет работать с разными версиями СУБД на ведущем и ведомом устройствах б) логическая репликация позволяет сделать реплику только тех данных, которые нам нужны, а не всех данных мастера один в один, и не блокирует слейв на запись И здесь перед нами открывается целый океан возможностей.
При первом ознакомлении с перечнем различных инструментов создания логической репликации и разнообразием самих техник репликации первое желание, которое возникает, — это желание сменить вид деятельности.
Но первый шок проходит, и мы начинаем отлавливать из этого океана достойных кандидатов на пост инструмента нашей мечты.
Полезная статья, в которой подробно рассматриваются вопросы репликации и поддерживающие ее утилиты, в том числе: postgresql.leopard.in.ua/html/#replicationНекоторые из наиболее популярных инструментов, используемых для этого, — это slony (на основе триггеров) и pgpool/pgpool-II (промежуточное ПО).
Скажу сразу, попытка решить эту проблему с помощью очень известной и популярной утилиты Slony версии 2.2.5 за две недели успехом не увенчалась - даже в том случае, когда в целях проверки концепции, и мастер, и реплика использовали одну и ту же версию PostgreSQL. Демон slony упорно отказывался запускаться и перезагружался сразу после запуска из-за ошибки сегментации, причину которой найти не удалось.
Да и искать причины ошибок сегментации в стороннем ПО — дело неблагодарное.
Причем одна и та же картина наблюдалась при компиляции этой утилиты из исходного кода и при установке из родного репозитория Alpine Linux. Этот эксперимент проводился со следующими исходными данными: - докер-контейнеры - как ведущий, так и ведомый: postgre 9.6 в Alpine Linux Вполне возможно, что причиной сбоя стали сами начальные условия — использование Docker или именно этого дистрибутива Linux — но в моем случае это были правила игры.
Также допускаю, что проблема могла скрываться в нестабильности самой последней версии Slony, которой я пользовался.
В любом случае это решение не сработало, и Слони ушел в отставку.
Возможно, в другой конфигурации системы или в другой версии Slony вам удастся это сделать.
Однако, прочитав остальную часть статьи, возможно, вам не захочется возиться с этой древней утилитой.
И не забывайте об этом: Howfuckedismydatabase.com/postgres/slony.php До второй утилиты pgpool я так и не добрался, потому что по пути нашел то, что в конечном итоге стало моим решением: утилиту пглогический из 2-го квадранта.
Прочитав документацию к утилите и осознав, кем был 2ndQuadrant, меня сразу привлекло это решение.
Забегая вперед, скажу, что судя по всему это решение может быть даже включено в грядущую 10-ю версию PostgreSQL как стандартное решение для логической репликации.
Поэтому было решено с этим поиграться, переместив в очередь исследования pgpool. Я решил сразу собрать систему из тех компонентов, которые должны были быть отправлены в производство позже, минуя этап проверки концепции: Владелец: докер-контейнер из того же образа, что и в первом случае Реплика: докер-контейнер PipelineDB из другое изображение , который вроде бы является официальным изображением этого проекта, хотя оформлен как-то странно.
Образ построен на дистрибутиве Debian, а не Alpine. Итак, я начал копаться в pgologic. Практически сразу меня ждало горькое разочарование: в репозитории APT эта утилита существует только для PostgreSQL версий 9.4, 9.5 и 9.6, а PipelineDB там нет и следа.
Утилита наотрез отказалась устанавливаться на хост с PipelineDB, сообщив о неудовлетворенной зависимости postgresql-9.5. Что.
чудесный эксперимент закончился, так и не начавшись.
Но осознание того, что PipelineDB — это всё тот же PostgreSQL — структура каталогов базы данных, файлов конфигурации, встроенных команд и сервисных утилит это наглядно доказывает — и что это должно привести меня к чему-то положительному, меня не покидало.
И я решился на небольшую хитрость.
Утилита pgologic устанавливается на хост с PipelineDB следующим образом (все делалось в Docker-контейнере под рутом): Добавляем репозиторий и скачиваем пакеты утилит:
Устанавливаем необходимые библиотеки и сам пакет, игнорируя зависимости (!), решая нашу проблему нежелания утилиты устанавливаться на что-либо кроме Postgre:echo "deb [arch=amd64] http://packages.2ndquadrant.com/pglogical/apt/ jessie-2ndquadrant main" > /etc/apt/sources.list.d/2ndquadrant.list wget --quiet -O - http://packages.2ndquadrant.com/pglogical/apt/AA7A6805.asc | apt-key add - apt-get update && apt-get download libpq5 postgresql-9.5-pglogical
dpkg -i --ignore-depends=postgresql-9.5 libpq5_9.4.10-0+deb8u1_amd64.deb
dpkg -i --ignore-depends=postgresql-9.5 postgresql-9.5-pglogical_1.2.2-1jessie_amd64.debУдаляем запись о зависимости из файла /var/lib/dpkg/status, чтобы при продолжении работы apt-get не жаловался на ненайденную зависимость и не предлагал нам удалить pgologic:
sed 's/, postgresql-9.5//g' /var/lib/dpkg/status > /var/lib/dpkg/status-new && \
mv /var/lib/dpkg/status /var/lib/dpkg/status.bkp && \
mv /var/lib/dpkg/status-new /var/lib/dpkg/statusВсе! Утилита устанавливается на хост с PipelineDB. Но опять незадача — утилита устанавливается в папки с именем postgresql, а PipelineDB имеет аналогичную структуру папок, но с именем Pipelinedb. Что ж, не будем расстраиваться по этому поводу и переместим файлы утилиты в соответствующие папки в PipelineDB:
mv /usr/lib/postgresql/9.5/lib/* /usr/lib/pipelinedb/lib/pipelinedb/
mv /usr/lib/postgresql/9.5/bin/* /usr/lib/pipelinedb/bin/
mv /usr/share/postgresql/9.5/extension/* /usr/lib/pipelinedb/share/pipelinedb/extension/Вот и все.
Теперь у нас есть работающий сервер PipelineDB с установленной утилитой pgologic, которую мы можем начать использовать.
После непродолжительной настройки master-slave-кластера (вы настраиваете реплику PipelineDB так же, как и обычный PostgreSQL), описание которого можно найти на миллионе ресурсов, включая документацию Postgre, и пройдя простые шаги настройки самой утилиты мы можем убедиться, что репликация работает. UPD: Исходники конфигураций и скриптов инициализации докера можно найти здесь: https://github.com/akrymets/pg-replication Буду рад услышать комментарии по сути и предложения по повествованию.
Лучшие предложения будут реализованы в виде правок статьи.
Теги: #Администрирование баз данных #postgresql #DevOps #pipelinedb #replication
-
Внедрение Openstack И Куда Двигаться Дальше?
19 Oct, 24
