[PostgreSQL, SQL, Администрирование баз данных] Расширение кластера PostgreSQL размером 5,7 ТБ и переход с версии 9.6 на 12.4 (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
оригинал
Фото Ричарда Джекобса на Unsplash
В ноябре 2020 года мы начали крупную миграцию для обновления кластера PostgreSQL с версии 9.6 на 12.4. В этом посте я вкратце расскажу про нашу архитектуру в компании Coffee Meets Bagel, объясню, как даунтайм апгрейда удалось снизить ниже 30 минут, и расскажу про то, что мы узнали в процессе.
Архитектура
Для справки: Coffee Meets Bagel — это приложение для романтических знакомств с системой курирования. Каждый день наши пользователи получают в полдень по их часовому поясу ограниченную партию высококачественных кандидатов. Это приводит к хорошо предсказуемым закономерностям нагрузки. Если посмотреть данные за последнюю неделю от момента написания статьи, у нас в среднем получается 30 тысяч транзакций в секунду, в пике — до 65 тысяч.
До обновления у нас работали 6 серверов Postgres на инстансах i3.8xlarge в AWS. Они содержали одну главную ноду, три реплики для раздачи веб-трафика только для чтения, балансируемые с помощью HAProxy, один сервер для асинхронных воркеров и один сервер для ETL [Extract, Transform, Load] и Business Intelligence.
Для поддержания парка реплик в актуальном состоянии мы полагаемся на встроенную в Postgres потоковую репликацию.
Причины для апгрейда
Последние несколько лет мы заметно игнорировали наш уровень данных, и как результат, он слегка устарел. Особенно много «костылей» поднабрал в себя наш основной сервер — он находится в онлайне уже 3,5 года. Различные системные библиотеки и службы мы патчим без остановок сервера.
Мой кандидат для подреддита r/uptimeporn
Как итог, накопилось множество странностей, которые заставляют понервничать. К примеру, новые сервисы в systemd не запускаются. Пришлось настраивать запуск агента datadog в сессии screen. Иногда SSH переставал отвечать при загрузке процессора выше 50 %, а сам сервер исправно отдавал запросы базы данных.
А ещё свободное место на диске начало подходить к опасным значениям. Как я упоминал выше, Postgres работал на инстансах i3.8xlarge в EC2, у которых 7,6 ТБ хранилища NVMe. В отличие от EBS, здесь размер диска динамически менять нельзя — что заложено изначально, то и будет. И мы заполнили примерно 75 % диска. Стало понятно, что для поддержания будущего роста размер инстанса придётся менять.
Наши требования
- Минимальный даунтайм. Мы поставили целью ограничение в 4 часа суммарного даунтайма, включая незапланированные отключения, вызванные ошибками при обновлении.
- Собрать новый кластер баз данных на новых инстансах для замены текущего парка стареющих серверов.
- Перейти на i3.16xlarge, чтобы был простор для роста.
Нам известны три способа выполнить обновление Postgres: создание резервной копии и восстановление из неё, pg_upgrade и логическая репликация pglogical.
От первого способа, восстановления из резервной копии, мы отказались сразу: для нашего датасета на 5,7 ТБ он занял бы слишком много времени. При своей скорости приложение pg_upgrade не удовлетворяло требованиям 2 и 3: это инструмент для миграции на той же машине. Поэтому мы выбрали логическую репликацию.
Наш процесс
Про ключевые особенности работы pglogical написано уже достаточно. Поэтому вместо повторения прописных истин я просто приведу статьи, которые оказались полезными для меня:
- Major-version upgrading with minimal downtime;
- Upgrading PostgreSQL from 9.4 to 10.3 with pglogical;
- Demystifying pglogical — Tutorial.
Мы создали новый primary-сервер Postgres 12 и с помощью pglogical синхронизировали все наши данные. Когда он синхронизировался и перешёл к репликации входящих изменений, мы начали добавлять за него потоковые реплики. После настройки новой потоковой реплики мы включали её в HAProxy, а одну из старых версии 9.6 удаляли.
Этот процесс продолжался до полного отключения серверов Postgres 9.6, кроме мастера. Конфигурация приняла следующий вид.
Затем настал черёд переключения кластера (failover), на что мы запросили окно технических работ. Процесс переключения тоже хорошо задокументирован в Интернете, поэтому я расскажу лишь про общие шаги:
- Перевод сайта в режим технических работ;
- Смена записей DNS мастера на новый сервер;
- Принудительная синхронизация всех последовательностей (sequences) первичных ключей (primary key);
- Ручной запуск контрольной точки (CHECKPOINT) на старом мастере.
- На новом мастере — выполнение некоторых процедур валидации данных и тестов;
- Включение сайта.
В целом, переход прошёл отлично. Несмотря на столь крупные изменения в нашей инфраструктуре, незапланированного даунтайма не случилось.
Извлечённые уроки
При общем успехе операции пара проблем по пути всё же встретилась. Самая страшная из них чуть не убила наш мастер Postgres 9.6…
Урок №1: медленная синхронизация может быть опасной
Обозначим для начала контекст: как работает pglogical? Процесс передачи (sender) на поставщике (provider, в данном случае наш старый мастер 9.6) декодирует упреждающий журнал WAL [write-ahead log], извлекает логические изменения и посылает их на подписчика (subscriber).
Если подписчик отстаёт, то поставщик будет хранить сегменты WAL, чтобы когда подписчик его нагонит, никаких данных не потерялось.
При первом добавлении таблицы в поток репликации приложению pglogical сначала нужно синхронизировать данные таблицы. Это выполняется с помощью команды Postgres COPY. После этого сегменты WAL начинают копиться на поставщике, чтобы изменения за время работы COPY получилось передать на подписчика после изначальной синхронизации, гарантируя отсутствие потери данных.
На практике это означает, что при синхронизации большой таблицы на системе с большой нагрузкой по записям/изменениям нужно тщательно следить за использованием диска. При первой попытке синхронизации нашей самой крупной (4 ТБ) таблицы команда с оператором COPY работала больше суток. За это время на ноде поставщика набралось больше одного терабайта упреждающих журналов WAL.
Как вы можете помнить по уже сказанному, на наших старых серверах баз данных оставалось всего по два терабайта свободного дискового пространства. Мы оценили по заполненности диска сервера подписчика, что скопировалась всего четверть таблицы. Поэтому процесс синхронизации пришлось немедленно остановить — диск на мастере кончился бы раньше.
Доступное дисковое пространство на старом мастере при первой попытке синхронизации
Чтобы ускорить процесс синхронизации, мы внесли следующие изменения в базу данных подписчика:
- Удалили все индексы в синхронизируемой таблице;
- fsynch переключили на off;
- Поменяли max_wal_size на 50GB;
- Поменяли checkpoint_timeout на 1h.
Эти четыре действия значительно ускорили процесс синхронизации на подписчике, и наша вторая попытка синхронизации таблицы завершилась за 8 часов.
Урок №2: каждое изменение строк журналируется как конфликт
Когда pglogical обнаруживает конфликт, приложение оставляет в логах запись вида «CONFLICT: remote UPDATE on relation PUBLIC.foo. Resolution: apply_remote».
Однако выяснилось, что каждое обработанное подписчиком изменение строк вносилось в журнал как конфликт. За несколько часов репликации база данных подписчика оставляла после себя гигабайты файлов логов с конфликтами.
Эту проблему удалось решить заданием параметра pglogical.conflict_log_level = DEBUG в файле postgresql.conf.
Об авторе
Томми Ли — старший инженер программного обеспечения в компании Coffee Meets Bagel. До этого он работал в Microsoft и канадском производителе систем автоматизирования бухгалтерского учёта Wave HQ.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Tommy Li
===========Похожие новости:
- [Open source, Администрирование баз данных, Big Data, Data Engineering] EventNative – простой инструмент для записи потока событий в ClickHouse (перевод)
- [Open source, PHP, PostgreSQL, GitHub, Laravel] Как подружить ltree и Laravel
- [Oracle, SQL] Эволюция моих SQL запросов
- [Администрирование баз данных, Big Data, Data Engineering] Аналитический движок Amazon Redshift + преимущества Облака
- [Oracle] Cli-IDE для oracle-субд. Ну. Почти IDE
- [Платежные системы, Разработка под e-commerce] Как мы сделали оплату по QR
- [Информационная безопасность, Анализ и проектирование систем, SQL, Администрирование баз данных, Геоинформационные сервисы] Внешний ключ должен вести не на сущность, а на актуальную версию этой сущности
- [Программирование, Облачные сервисы, Микросервисы] Введение в паттерн распределенной трассировки (перевод)
- [Системное администрирование, Серверное администрирование, Администрирование баз данных, Хранение данных] Понимание LDAP-протокола, иерархии данных и компонентов записей (перевод)
- [Системное администрирование, Серверное администрирование, 1С] Чек-лист по настройке инфраструктуры для повышения скорости работы 1С с MS SQL (особенно важно в облаках)
Теги для поиска: #_postgresql, #_sql, #_administrirovanie_baz_dannyh (Администрирование баз данных), #_postgresql, #_bazy_dannyh (базы данных), #_amazon_web_services, #_aws, #_ec2, #_coffee_meets_bagel, #_migratsija_bazy_dannyh (миграция базы данных), #_pglogical, #_postgresql_9.6, #_postgresql_12.4, #_postgresql_12, #_blog_kompanii_alfabank (
Блог компании Альфа-Банк
), #_postgresql, #_sql, #_administrirovanie_baz_dannyh (
Администрирование баз данных
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:22
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 оригинал Фото Ричарда Джекобса на Unsplash В ноябре 2020 года мы начали крупную миграцию для обновления кластера PostgreSQL с версии 9.6 на 12.4. В этом посте я вкратце расскажу про нашу архитектуру в компании Coffee Meets Bagel, объясню, как даунтайм апгрейда удалось снизить ниже 30 минут, и расскажу про то, что мы узнали в процессе. Архитектура Для справки: Coffee Meets Bagel — это приложение для романтических знакомств с системой курирования. Каждый день наши пользователи получают в полдень по их часовому поясу ограниченную партию высококачественных кандидатов. Это приводит к хорошо предсказуемым закономерностям нагрузки. Если посмотреть данные за последнюю неделю от момента написания статьи, у нас в среднем получается 30 тысяч транзакций в секунду, в пике — до 65 тысяч.  До обновления у нас работали 6 серверов Postgres на инстансах i3.8xlarge в AWS. Они содержали одну главную ноду, три реплики для раздачи веб-трафика только для чтения, балансируемые с помощью HAProxy, один сервер для асинхронных воркеров и один сервер для ETL [Extract, Transform, Load] и Business Intelligence. Для поддержания парка реплик в актуальном состоянии мы полагаемся на встроенную в Postgres потоковую репликацию.  Причины для апгрейда Последние несколько лет мы заметно игнорировали наш уровень данных, и как результат, он слегка устарел. Особенно много «костылей» поднабрал в себя наш основной сервер — он находится в онлайне уже 3,5 года. Различные системные библиотеки и службы мы патчим без остановок сервера.  Мой кандидат для подреддита r/uptimeporn Как итог, накопилось множество странностей, которые заставляют понервничать. К примеру, новые сервисы в systemd не запускаются. Пришлось настраивать запуск агента datadog в сессии screen. Иногда SSH переставал отвечать при загрузке процессора выше 50 %, а сам сервер исправно отдавал запросы базы данных. А ещё свободное место на диске начало подходить к опасным значениям. Как я упоминал выше, Postgres работал на инстансах i3.8xlarge в EC2, у которых 7,6 ТБ хранилища NVMe. В отличие от EBS, здесь размер диска динамически менять нельзя — что заложено изначально, то и будет. И мы заполнили примерно 75 % диска. Стало понятно, что для поддержания будущего роста размер инстанса придётся менять. Наши требования
Нам известны три способа выполнить обновление Postgres: создание резервной копии и восстановление из неё, pg_upgrade и логическая репликация pglogical. От первого способа, восстановления из резервной копии, мы отказались сразу: для нашего датасета на 5,7 ТБ он занял бы слишком много времени. При своей скорости приложение pg_upgrade не удовлетворяло требованиям 2 и 3: это инструмент для миграции на той же машине. Поэтому мы выбрали логическую репликацию. Наш процесс Про ключевые особенности работы pglogical написано уже достаточно. Поэтому вместо повторения прописных истин я просто приведу статьи, которые оказались полезными для меня:
Мы создали новый primary-сервер Postgres 12 и с помощью pglogical синхронизировали все наши данные. Когда он синхронизировался и перешёл к репликации входящих изменений, мы начали добавлять за него потоковые реплики. После настройки новой потоковой реплики мы включали её в HAProxy, а одну из старых версии 9.6 удаляли. Этот процесс продолжался до полного отключения серверов Postgres 9.6, кроме мастера. Конфигурация приняла следующий вид.  Затем настал черёд переключения кластера (failover), на что мы запросили окно технических работ. Процесс переключения тоже хорошо задокументирован в Интернете, поэтому я расскажу лишь про общие шаги:
В целом, переход прошёл отлично. Несмотря на столь крупные изменения в нашей инфраструктуре, незапланированного даунтайма не случилось. Извлечённые уроки При общем успехе операции пара проблем по пути всё же встретилась. Самая страшная из них чуть не убила наш мастер Postgres 9.6… Урок №1: медленная синхронизация может быть опасной Обозначим для начала контекст: как работает pglogical? Процесс передачи (sender) на поставщике (provider, в данном случае наш старый мастер 9.6) декодирует упреждающий журнал WAL [write-ahead log], извлекает логические изменения и посылает их на подписчика (subscriber). Если подписчик отстаёт, то поставщик будет хранить сегменты WAL, чтобы когда подписчик его нагонит, никаких данных не потерялось. При первом добавлении таблицы в поток репликации приложению pglogical сначала нужно синхронизировать данные таблицы. Это выполняется с помощью команды Postgres COPY. После этого сегменты WAL начинают копиться на поставщике, чтобы изменения за время работы COPY получилось передать на подписчика после изначальной синхронизации, гарантируя отсутствие потери данных. На практике это означает, что при синхронизации большой таблицы на системе с большой нагрузкой по записям/изменениям нужно тщательно следить за использованием диска. При первой попытке синхронизации нашей самой крупной (4 ТБ) таблицы команда с оператором COPY работала больше суток. За это время на ноде поставщика набралось больше одного терабайта упреждающих журналов WAL. Как вы можете помнить по уже сказанному, на наших старых серверах баз данных оставалось всего по два терабайта свободного дискового пространства. Мы оценили по заполненности диска сервера подписчика, что скопировалась всего четверть таблицы. Поэтому процесс синхронизации пришлось немедленно остановить — диск на мастере кончился бы раньше.  Доступное дисковое пространство на старом мастере при первой попытке синхронизации Чтобы ускорить процесс синхронизации, мы внесли следующие изменения в базу данных подписчика:
Эти четыре действия значительно ускорили процесс синхронизации на подписчике, и наша вторая попытка синхронизации таблицы завершилась за 8 часов. Урок №2: каждое изменение строк журналируется как конфликт Когда pglogical обнаруживает конфликт, приложение оставляет в логах запись вида «CONFLICT: remote UPDATE on relation PUBLIC.foo. Resolution: apply_remote». Однако выяснилось, что каждое обработанное подписчиком изменение строк вносилось в журнал как конфликт. За несколько часов репликации база данных подписчика оставляла после себя гигабайты файлов логов с конфликтами. Эту проблему удалось решить заданием параметра pglogical.conflict_log_level = DEBUG в файле postgresql.conf. Об авторе  Томми Ли — старший инженер программного обеспечения в компании Coffee Meets Bagel. До этого он работал в Microsoft и канадском производителе систем автоматизирования бухгалтерского учёта Wave HQ. =========== Источник: habr.com =========== =========== Автор оригинала: Tommy Li ===========Похожие новости:
Блог компании Альфа-Банк ), #_postgresql, #_sql, #_administrirovanie_baz_dannyh ( Администрирование баз данных ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:22
Часовой пояс: UTC + 5