Рубрика «replication»

Довольно типичная схема при разработке системы, когда основная логика обработки сосредоточена в приложении (в нашем случае Erlang), а данные для работы этого приложения (настройки, профили пользователей и т. д.) в базе данных (PostgreSQL). Приложение Erlang кэширует настройки в ETS для ускорения обработки и снижения нагрузки на БД путём отказа от постоянных запросов. При этом изменение этих данных происходит через отдельный (возможно, внешний) сервис.

В таких ситуациях встаёт задача поддержания закэшированных данных в актуальном состоянии. Есть разные подходы для решения этой задачи. Один из них — это логическая репликация PostgreSQL. О нем и пойдёт речь ниже.

Читать полностью »

Архитектура AERODISK vAIR или особенности национального кластеростроения - 1

Привет, Хабровчане! Мы продолжаем знакомить вас с российской гиперконвергентной системой AERODISK vAIR. В этой статье речь пойдет об архитектуре данной системы. В прошлой статье мы разобрали нашу файловую систему ARDFS, а в данной статье пройдёмся по всем основным программным компонентам, из которых состоит vAIR, и по их задачам.

Читать полностью »

Перекрестная репликация между PostgreSQL и MySQL - 1
Я в общих чертах расскажу о перекрестной репликации между PostgreSQL и MySQL, а еще о методах настройки перекрестной репликации между этими двумя серверами базы данных. Обычно базы данных в перекрестной репликации называются однородными, и это удобный метод перехода с одного сервера реляционной СУБД на другой.

Базы данных PostgreSQL и MySQL принято считать реляционными, но с дополнительными расширениями они предлагают возможности NoSQL. Здесь мы обсудим репликацию между PostgreSQL и MySQL, с точки зрения реляционных СУБД.

Мы не будем описывать всю внутреннюю кухню, только базовые принципы, чтобы вы получили представление о настройке репликации между серверами баз данных, преимуществах, ограничениях и сценариях использования.

Читать полностью »

Почему DFSR не реплицирует некоторые файлы и как с этим бороться - 1
Как многим известно, в свойствах реплицируемых папок можно настроить исключения в виде масок файлов — и тогда служба не будет реплицировать файлы, соответствующие заданным маскам. Но не все знают, что у файлов есть атрибут «временный», и DFSR не обрабатывает такие файлы by design. И если это не учесть, то может случиться так, что содержимое ваших DFSR-папок станет рассинхронизированным, хотя в логах службы всё будет чисто и красиво, и всплыть это может в самый неподходящий момент. Сама проблема и ее решение уже не раз разбирались в интернете, цель же этой статьи — доработать созданное ранее решение, добавив ему гибкости и удобства. Для кого актуально — прошу под кат.
Читать полностью »

Непрерывная репликация из старой в новую версию PostgreSQL с помощью Slony - 1

Нативная потоковая репликация в PostgreSQL работает только между серверами с одинаковой основной версией. О логической репликации мы говорили в предыдущем посте. Мы увидели, как логическая репликация помогает перенести данные из одной версии PostgreSQL в другую. Но логическая репликация подходит только для поддерживаемых версий PostgreSQL, например, для PostgreSQL 9.4 и PostgreSQL 11. Что делать с версиями до 9.4? Использовать Slony-I.

Используйте репликацию с помощью Slony-I, чтобы перенести данные из старых баз в последнюю версию PostgreSQL. Что такое Slony и как он работает?

Читать полностью »

Логическая репликация между версиями PostgreSQL - 1

Есть разные подходы к обновлению PostgreSQL, но некоторые приводят к простою приложения. Если нужно избежать простоя, используйте для обновления репликацию — логическую или физическую (потоковую), в зависимости от сценария. В этой статье мы рассмотрим разницу между логической и физической репликацией в PostgreSQL. Затем подробно поговорим, как обновить версию с помощью логической репликации и при этом избежать простоя приложения. В следующей статье обсудим репликацию физическую.

В предыдущих статьях мы уже говорили о методах обновления PostgreSQL (Обновление версии PostgreSQL с помощью pg_dumpall и Обновление версии PostgreSQL с помощью pg_dump/pg_restore) в рамках серии Обновление или миграция старых версий PostgreSQL в новые. Но оба этих метода не исключают простоя.

Читать полностью »

Привет, я занимаюсь созданием приложений для СУБД Tarantool — это разработанная в Mail.ru Group платформа, совмещающая в себе высокопроизводительную СУБД и сервер приложений на языке Lua. Высокая скорость работы решений, основанных на Tarantool, достигается в частности за счет поддержки in-memory режима СУБД и возможности выполнения бизнес-логики приложения в едином адресном пространстве с данными. При этом обеспечивается персистентность данных с использованием ACID-транзакций (на диске ведется WAL-журнал). В Tarantool имеется встроенная поддержка репликации и шардирования. Начиная с версии 2.1, поддерживаются запросы на языке SQL. Tarantool имеет открытый исходный код и распространяется под лицензией Simplified BSD. Также имеется коммерческая Enterprise-версия.

Высокоуровневая репликация в СУБД Tarantool - 1
Feel the power! (...aka enjoy the performance)

Все перечисленное делает Tarantool привлекательной платформой для создания высоконагруженных приложений, работающих с БД. В таких приложениях часто возникает необходимость репликации данных.
Читать полностью »

Как мы использовали отложенную репликацию для аварийного восстановления с PostgreSQL - 1
Репликация — не бэкап. Или нет? Вот как мы использовали отложенную репликацию для восстановления, случайно удалив ярлыки.

Специалисты по инфраструктуре на GitLab отвечают за работу GitLab.com — самого большого экземпляра GitLab в природе. Здесь 3 миллиона пользователей и почти 7 миллионов проектов, и это один из самых крупных опенсорс-сайтов SaaS с выделенной архитектурой. Без системы баз данных PostgreSQL инфраструктура GitLab.com далеко не уедет, и что мы только не делаем для отказоустойчивости на случаи любых сбоев, когда можно потерять данные. Вряд ли такая катастрофа случится, но мы хорошо подготовились и запаслись разными механизмами бэкапа и репликации.

Репликация — это вам не средство бэкапа баз данных (см. ниже). Но сейчас мы увидим, как быстро восстановить случайно удаленные данные с помощью отложенной репликации: на GitLab.com пользователь удалил ярлык для проекта gitlab-ce и потерял связи с мерж-реквестами и задачами.

С отложенной репликой мы восстановили данные всего за 1,5 часа. Смотрите, как это было.

Читать полностью »

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с помощью стороннего плагина под названием pglogical.

В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.

Бесшовная (почти) миграция между мажорными релизами PostgreSQL с помощью логической репликации - 1

TL;DR

  • Всё получилось (не без костылей, о них и статья).
  • Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
  • Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

Читать полностью »

i break you recoveryВ PostgreSQL начиная с очень давних времён аж версии 8.0 вышедшей в далёком 2005 году для восстановления в определённую точку времени использовался специальный файл конфигурации recovery.conf. Этот же файл впоследствии стал использоваться для режима standby и потоковой репликации.

Однако начиная со следующего релиза PostgreSQL 12 больше recovery.conf работать не будет: я его сломал.
Но зачем?
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js