Comments 15
Опыт ценный, но по всей статье красные флаги.
- СУБД для толстой базы с >50% утилизацией диска. Если диск занят на >50% такой сервер не может хранить вторую копию данных. Невозможно иметь "старую базу в соседнем каталоге когда бэкап восстанавливается", невозможно сделать копию базы для каких-то экспериментов или разбирательств. Только сеть, а она на таких объёмах ой какая медленная. И никакого быстрого
mv. - Апгрейд развёртыванием бэкапа не был опцией из-за сроков, что означает, что у них и восстановление из бэкапов тоже по срокам не проходит. Если восстановить из бэкапов за разумное время нельзя, то ой, нарушение SLO в полный рост. TTR больше допустимого в разы. Ещё мне показалось, что они эти бэкапы не тестируют (хотя я могу клеветать, извините).
- отключение fsync на продакшен базе. Это уже вообще leap of faith (если я зажмурив глаза буду быстро-быстро перебегать хайвей, то меня не собьют — я так уже два раза делал и всё ок!).
В целом — классический геоизм по определению "героизм одних это последствия халатности других".
fsync же был на подписчике на время копирования отключён. В этом нет ничего страшного. В худшем случае, при сбое подписчика пришлось бы просто всё заново прогонять. А после окончания копирования они наверняка fsync включили. Да, и вероятность крэша сервера подписчика низкая, и самое главное, в случае крэша даже с fsync доверия к результату копирования с крэшем быть не может — раз крэш был, то там уже что-то где-то некорректно представлено.
В общем, это совершенно нормальная практика — подписчик ещё не является продакшином. Он станет продакшином после окончания копирования, настройки и прогонки тестов — вот, тогда ай-ай-ай за такие фокусы. И то в тяжёлый случаях вполне можно вывести сервер из работы, сделать грязное дело без fsync и вернуть в работу.
В общем, это совершенно нормальная практика — подписчик ещё не является продакшином. Он станет продакшином после окончания копирования, настройки и прогонки тестов — вот, тогда ай-ай-ай за такие фокусы. И то в тяжёлый случаях вполне можно вывести сервер из работы, сделать грязное дело без fsync и вернуть в работу.
А что, pglogical — он горизонтально масштабируется? Просто эти вот упомянутые единицы терабайт — на сегодня далеко не предел. Можно построить репликацию, чтобы процессов было много, и на разных машинах? До какого предела?
Ну так они походу под базу вообще instance storage используют в raid 0
>При первой попытке синхронизации нашей самой крупной (4 ТБ) таблицы
А партициирование бы помогло?
А партициирование бы помогло?
Как страшно жить. В 2021 году 5 терабайт БД мигрируется больше суток. А ведь 5 ТБ — это как 2 винчестера современного ноутбука или как один гейминг-комп. И, главное, свой личный опыт подсказывает, что все эти цифры вполне реалистичны, эффективнее фиг получится сделать нахрапом. Куда-то мы все не туда идем, ох не туда… как бы не вымереть, как динозавры вымерли.
Не очень понятно, зачем эта морока с одновременным апгрейдом postgres и переездом на новые сервера? Что мешало сначала поднять копию инфраструктуры на той же версии postgres при помощи обычной потоковой репликации, а затем быстренько ее проапгрейдить pg_upgrade?
Судя по вашим рассуждениям видно что вы никогда не мигрировали с одной версии на другую, более менее приличный объем данных. Без остановки продакшена на сутки и более… К тому же эта чудо утилита то же достаточно странно работает. А когда разница между версиями 3 мажорных релиза, не известно как она отработает. Чего стоит переименование всех функций относящихся к wal и самих журналов, все критичные изменения не вспомню. Но из за этих мониторинг пришлось в срочном порядке допиливать.
Лично мы в 2020 делали апгрейд с Postgres 9.6 до Postgres 11. БД примерно на 1ТБ (сейчас уже почти 1.5ТБ). Как раз переносили БД с одного сервера на другой. Ещё у нас есть три реплики.
Всё сделали с помощью pgbasebackup + pg_upgrade. А точнее так:
1) На новом сервере установили postgres 9.6
2) С помощью pg_basebackup создали ещё одну реплику на новом сервере с помощью потоковой репликации
3) Когда пришло время, погасили прод-сервер
4) Удалили на новом мастере recovery.conf, сделали на нём апгрейд с 9.6 до 11 с помощью pg_upgrade
5) Переключили приложение на новый сервер БД
6) Сделали ещё три реплики
На всё ушло менее двух часов. Так что я бы не сказал, что обязательно уйдёт много времени. Всё зависит от сети и скорости дисков.
Всё сделали с помощью pgbasebackup + pg_upgrade. А точнее так:
1) На новом сервере установили postgres 9.6
2) С помощью pg_basebackup создали ещё одну реплику на новом сервере с помощью потоковой репликации
3) Когда пришло время, погасили прод-сервер
4) Удалили на новом мастере recovery.conf, сделали на нём апгрейд с 9.6 до 11 с помощью pg_upgrade
5) Переключили приложение на новый сервер БД
6) Сделали ещё три реплики
На всё ушло менее двух часов. Так что я бы не сказал, что обязательно уйдёт много времени. Всё зависит от сети и скорости дисков.
Я регулярно, с 9.6 версии, мигрирую пяток проектов, объемы баз 1-7 ТБ. Именно по озвученной схеме. Через три релиза — да, не пробовал, мы мигрируем на каждый новый релиз (не всегда меняя сервер), но я не думаю что возникнут какие-то кардинальные проблемы. В любом случае, всегда есть возможность при каких-то проблемах откатиться на старый сервер. Чудо-утилита с магическим ключиком -k работает очень быстро и не подводила ни разу. Использование pglogical никак не поможет при проблемах c переименованием xlog в wal или необходимостьи переделывать мониторинг.
pglogical для копирования синхронизации таблиц это тот еще инструмент. Не знаю как сейчас, а в свое время при попытке попользоваться им при миграции с 9.5 на 10. Вышло все печально, просто впустую потраченное время 2 суток на таблицу в 1,7ТБ, потом стало заканчиваться место на диске и пришлось это безобразие остановить. Взять londiste и без проблем перенести данные за вменяемое время. Без ужимок и прыжков с логами, ошибок в них от этой чудесной штуки. И снежного кома не удаленных wal журналов, которые в итоге чуть не остановили сервер(linux если выбрать место на диске в 0 перестает отвечать). Не рассчитана она на более менее приличный объем данных. Мне повезло, вовремя заметил что места почти нет и остановил репликацию. 4 ТБ wal журналов это круто, т.е. не удалялись журналы с начала репликации.
Sign up to leave a comment.
Расширение кластера PostgreSQL размером 5,7 ТБ и переход с версии 9.6 на 12.4