Comments 9
Спасибо за ценную информацию и практическую иллюстрацию . В закладках.
Хорошая статья, спасибо. Неплохо бы поправить форматирование кода - чтоб в блоке был, а не построчно.
Сколько времени у вас заняла подготовка - от планирования шагов до подготовки сервера (до начала репликации)?
У вас только одна база, без реплик? Насколько активно пишете в базу? Как отличалась загрузка на базе за время репликации от нормальной? Сколько клиентов на запись и чтение? Используете ли какие-то балансировщики типа pgbouncer/pgpool? Были ли какие-то ошибки у клиентов за время переключения?
При логической репликации - я правильно понимаю, что автогенерированные значения теоретически могут отличаться от источника?
Спасибо, поправил, постарался в блоки поместить. Буду отвечать частями, на что сразу смогу сначала.
Сколько времени у вас заняла подготовка - от планирования шагов до подготовки сервера
Точно боюсь наврать и занизить. Дня 3 (не полных рабочих) на тестовом стенде сделал и шаги записал из них 2 подготовка и третий включение репликации.
На Проде дня 2, 1 день подготовка машины (или 2 дня по 2-4 часа) и один день включение репликации и параллельно набросал статью.
У вас только одна база, без реплик?
Статью я писал по одной базе, но похожее делал и где несколько. (в статье на которую ссылаюсь автор как раз пишет когда несколько баз и как высчитывать max_wal_senders , slots). Параллельно еще работало 2 потоковые репликации на Standby и Barman.
Насколько активно пишете в базу?
Про которую пишу, не очень активно - около 3тыс Commits per sec.
Как отличалась загрузка на базе за время репликации от нормальной?
Делалось в праздники когда нагрузка со стороны минимальна. Не заметил отклонений от штатной работы. Только на момент первичной синхронизации отдельный сетевой интерфейс для репликации на 600Mb/s поднялся сутки+, потом спало на 300Mb/s сутки и оставшееся время чуть больше 200Mb/s и за 3,5 дня пришло в штатное состояние.
Используете ли какие-то балансировщики типа pgbouncer/pgpool?
По примеру из статьи - нет. У сервисов где-то 600 соединений.
у меня вот на работе с 9.6 надо обновляться...
Делал подобное, после переключения был сюрприз - sequence's не перенеслись. Не забудьте про это если они есть в вашей базе)
кстати, "о птичках", т.е. о секционированных таблицах.
если публикация у вас не дефолтная, а по уникальному индексу или full, то придется устанавливать правило репликации для каждой секции, установка по родителю REPLICA IDENTITY не работает.
хорошо, если секций всего-то с десяток, а вот если под сотню, то будет тут конкретный геморрой.
особенно геморно, если репликация по уникальному индексу - сначала сделал уникальный индекс по парентовой таблице, потом посмотрел, как этот индекс называется для каждой конкретной секции, только потом сделал alter table для каждой секции.
наверно можно тоже как-то автоматизировать, но мне сходу в голову не пришло.
Вкину пару кейсов.
На больших объемах еще помогает ускориться в копировании - перед созданием подписки на больших таблицах удалить индексы(если они не уникальные и не являются частью констрейнтов), а после того, как статус таблицы сменится на 'd' - индекс можно будет в конкурентном режиме построить как и был.
Еще кейс с расширением postgis и вариантом publication for all tables - можно споткнуться о таблицу этого расширения с одной строкой и уник. индексом.
Представьте: нужно обновить базу данных размером с небольшое озеро — целых 10 ТБ. Классические методы тут не работают.
Вот интересно какие классические методы тут не работают? Классический метод major апгрейдов - это pg_upgrade. Для больших объемов явно рекомендуется использовать ключ --link дабы избежать копирования файлов данных. Он тут не работает ? С какими непреодолимыми трудностями вы столкнулись ?
Я поищу, находил в документации. Читал pg_upgrade на одну-две версии обновит, чем больше, тем вероятнее, что не тестировалось (у меня 6 версий скачок) и есть известные проблемы - "вы можете получить ошибку при проведении REINDEX'a предыдущей версии PostgreSQL". Большая вероятность проблемы, откатить просто не получится обратно. Придется переходить на реплику и чинить кластер.
Еще я заодно и ОС обновил, не разбивая на 2 операции
Апгрейд Postgres с 11 до 17 версии без боли: мой гайд по логической репликации