Привет! Я Тимур Низамутдинов, DevOps-инженер компании «Флант». Недавно мне потребовалось обновить кластер PostgreSQL, который обрабатывает более 20 000 транзакций в секунду и состоит из мастера и реплики, с версии 13 до 16 с минимальным простоем. Помимо перехода на более актуальную версию, это решало и ряд существующих проблем, связанных с производительностью и поддержкой.
Рубрика «replication»
Как обновить PostgreSQL и не потерять данные: метод минимизации простоя
2024-12-17 в 6:00, admin, рубрики: devops, logical replication, postgres, postgresql, replication, логическая репликация, репликация, репликация баз данных, физическая репликацияЛогическая репликация из PostgreSQL в Erlang
2019-12-29 в 14:22, admin, рубрики: erlang, Erlang/OTP, postgresql, replicationДовольно типичная схема при разработке системы, когда основная логика обработки сосредоточена в приложении (в нашем случае Erlang), а данные для работы этого приложения (настройки, профили пользователей и т. д.) в базе данных (PostgreSQL). Приложение Erlang кэширует настройки в ETS для ускорения обработки и снижения нагрузки на БД путём отказа от постоянных запросов. При этом изменение этих данных происходит через отдельный (возможно, внешний) сервис.
В таких ситуациях встаёт задача поддержания закэшированных данных в актуальном состоянии. Есть разные подходы для решения этой задачи. Один из них — это логическая репликация PostgreSQL. О нем и пойдёт речь ниже.
Архитектура AERODISK vAIR или особенности национального кластеростроения
2019-11-11 в 2:00, admin, рубрики: Aerodisk, erasure codes, Erasure Coding, HCI, high availability, hyperconverged, hyperconverged cluster, IOPS, linux, replication, SAN, scale-out, storage, Блог компании AERODISK, гиперконвергентная система, гиперконвергентность, гиперконвергентные платформы, гиперконвергентные системы, гиперконвергенция, импортозамещение, отказоустойчивость, репликация, российское оборудование, Серверное администрирование, система хранения данных, системное администрирование, СХД, хранение данных, хранилища данныхПривет, Хабровчане! Мы продолжаем знакомить вас с российской гиперконвергентной системой AERODISK vAIR. В этой статье речь пойдет об архитектуре данной системы. В прошлой статье мы разобрали нашу файловую систему ARDFS, а в данной статье пройдёмся по всем основным программным компонентам, из которых состоит vAIR, и по их задачам.
Перекрестная репликация между PostgreSQL и MySQL
2019-09-13 в 11:58, admin, рубрики: devops, mysql, postgresql, replication, Блог компании Southbridge, Серверное администрирование, системное администрирование
Я в общих чертах расскажу о перекрестной репликации между PostgreSQL и MySQL, а еще о методах настройки перекрестной репликации между этими двумя серверами базы данных. Обычно базы данных в перекрестной репликации называются однородными, и это удобный метод перехода с одного сервера реляционной СУБД на другой.
Базы данных PostgreSQL и MySQL принято считать реляционными, но с дополнительными расширениями они предлагают возможности NoSQL. Здесь мы обсудим репликацию между PostgreSQL и MySQL, с точки зрения реляционных СУБД.
Мы не будем описывать всю внутреннюю кухню, только базовые принципы, чтобы вы получили представление о настройке репликации между серверами баз данных, преимуществах, ограничениях и сценариях использования.
Почему DFSR не реплицирует некоторые файлы и как с этим бороться
2019-07-06 в 15:30, admin, рубрики: dfs, DFSR, distributed file system, file server, powershell, replication, temporary attribute, Windows Server, временный атрибут, репликация, Серверная оптимизация, Серверное администрирование, системное администрирование, файловый сервер
Как многим известно, в свойствах реплицируемых папок можно настроить исключения в виде масок файлов — и тогда служба не будет реплицировать файлы, соответствующие заданным маскам. Но не все знают, что у файлов есть атрибут «временный», и DFSR не обрабатывает такие файлы by design. И если это не учесть, то может случиться так, что содержимое ваших DFSR-папок станет рассинхронизированным, хотя в логах службы всё будет чисто и красиво, и всплыть это может в самый неподходящий момент. Сама проблема и ее решение уже не раз разбирались в интернете, цель же этой статьи — доработать созданное ранее решение, добавив ему гибкости и удобства. Для кого актуально — прошу под кат.
Читать полностью »
Непрерывная репликация из старой в новую версию PostgreSQL с помощью Slony
2019-07-01 в 9:27, admin, рубрики: continuous replication, devops, postgresql, replication, slonic, Блог компании Southbridge, Серверное администрирование, системное администрированиеНативная потоковая репликация в PostgreSQL работает только между серверами с одинаковой основной версией. О логической репликации мы говорили в предыдущем посте. Мы увидели, как логическая репликация помогает перенести данные из одной версии PostgreSQL в другую. Но логическая репликация подходит только для поддерживаемых версий PostgreSQL, например, для PostgreSQL 9.4 и PostgreSQL 11. Что делать с версиями до 9.4? Использовать Slony-I.
Используйте репликацию с помощью Slony-I, чтобы перенести данные из старых баз в последнюю версию PostgreSQL. Что такое Slony и как он работает?
Логическая репликация между версиями PostgreSQL
2019-06-25 в 7:24, admin, рубрики: devops, logical replication, postgresql, replication, Блог компании Southbridge, Серверное администрирование, системное администрированиеЕсть разные подходы к обновлению PostgreSQL, но некоторые приводят к простою приложения. Если нужно избежать простоя, используйте для обновления репликацию — логическую или физическую (потоковую), в зависимости от сценария. В этой статье мы рассмотрим разницу между логической и физической репликацией в PostgreSQL. Затем подробно поговорим, как обновить версию с помощью логической репликации и при этом избежать простоя приложения. В следующей статье обсудим репликацию физическую.
В предыдущих статьях мы уже говорили о методах обновления PostgreSQL (Обновление версии PostgreSQL с помощью pg_dumpall и Обновление версии PostgreSQL с помощью pg_dump/pg_restore) в рамках серии Обновление или миграция старых версий PostgreSQL в новые. Но оба этих метода не исключают простоя.
Высокоуровневая репликация в СУБД Tarantool
2019-06-07 в 9:31, admin, рубрики: highload, in-memory database, Lua, replication, tarantool, Администрирование баз данных, Блог компании Mail.Ru Group, высокая производительность, Серверная оптимизацияПривет, я занимаюсь созданием приложений для СУБД Tarantool — это разработанная в Mail.ru Group платформа, совмещающая в себе высокопроизводительную СУБД и сервер приложений на языке Lua. Высокая скорость работы решений, основанных на Tarantool, достигается в частности за счет поддержки in-memory режима СУБД и возможности выполнения бизнес-логики приложения в едином адресном пространстве с данными. При этом обеспечивается персистентность данных с использованием ACID-транзакций (на диске ведется WAL-журнал). В Tarantool имеется встроенная поддержка репликации и шардирования. Начиная с версии 2.1, поддерживаются запросы на языке SQL. Tarantool имеет открытый исходный код и распространяется под лицензией Simplified BSD. Также имеется коммерческая Enterprise-версия.
Feel the power! (...aka enjoy the performance)
Все перечисленное делает Tarantool привлекательной платформой для создания высоконагруженных приложений, работающих с БД. В таких приложениях часто возникает необходимость репликации данных.
Читать полностью »
Как мы использовали отложенную репликацию для аварийного восстановления с PostgreSQL
2019-03-26 в 16:38, admin, рубрики: devops, gitlab, open source, point in time recovery, postgresql, recovery, replication, Блог компании Southbridge, Серверное администрирование, системное администрирование
Репликация — не бэкап. Или нет? Вот как мы использовали отложенную репликацию для восстановления, случайно удалив ярлыки.
Специалисты по инфраструктуре на GitLab отвечают за работу GitLab.com — самого большого экземпляра GitLab в природе. Здесь 3 миллиона пользователей и почти 7 миллионов проектов, и это один из самых крупных опенсорс-сайтов SaaS с выделенной архитектурой. Без системы баз данных PostgreSQL инфраструктура GitLab.com далеко не уедет, и что мы только не делаем для отказоустойчивости на случаи любых сбоев, когда можно потерять данные. Вряд ли такая катастрофа случится, но мы хорошо подготовились и запаслись разными механизмами бэкапа и репликации.
Репликация — это вам не средство бэкапа баз данных (см. ниже). Но сейчас мы увидим, как быстро восстановить случайно удаленные данные с помощью отложенной репликации: на GitLab.com пользователь удалил ярлык для проекта gitlab-ce
и потерял связи с мерж-реквестами и задачами.
С отложенной репликой мы восстановили данные всего за 1,5 часа. Смотрите, как это было.
Бесшовная (почти) миграция между мажорными релизами PostgreSQL с помощью логической репликации
2019-01-24 в 6:43, admin, рубрики: devops, high availability, linux, postgresql, replication, Администрирование баз данных, Блог компании True Engineering, высокая производительность, отказоустойчивостьУ нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.
Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.
Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.
Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с помощью стороннего плагина под названием pglogical.
В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.
TL;DR
- Всё получилось (не без костылей, о них и статья).
- Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
- Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).