Comments 15
Самое важное забыли. Разворачивание резервных копий при условии тотального уничтожения сервера постгрес
Ну почему забыл, «это только присказка, сказка впереди». Это первая часть, вся последняя часть будет про то как восстанавливаться.
проблема в том, что сам бэкап делается быстро и pg_dumpall, а вот restore это отдельная боль, особенно, если база стоит на hdd и у вас медленный(низкой частоты) процессор, и в итоге мы приходим к тому, что при базах свыше 40 тб большая часть способов бэкапа пг бесполезные практически
Ну чудес не бывает, Вам как-то нужно принести на машину 40TB данных, какой-то постгресовой специфики в этом вопросе нет.
В зависимости от ситуации и используемого инструмента возможны различные оптимизации, которые позволяют ускорить этот процесс, например, инкрементальное восстановление в уже существующий кластер. Переиспользуя валидные страницы можно здорово сократить объем данных, который надо прокачать по сети и записать на диск, но за это придется заплатить полным перечитыванием уже имеющегося кластера.
В зависимости от ситуации и используемого инструмента возможны различные оптимизации, которые позволяют ускорить этот процесс, например, инкрементальное восстановление в уже существующий кластер. Переиспользуя валидные страницы можно здорово сократить объем данных, который надо прокачать по сети и записать на диск, но за это придется заплатить полным перечитыванием уже имеющегося кластера.
проблема в том, что даже это не до конца помогает, причём даже на небольших объёмах, например pg_dump иногда игнорирует некоторые записи, и при переносе базы на новый сервер через backup вы имеете отставание на n записей, а настроить репликацию тоже можно не всегда.
Приведу пример, есть бд, размер 30 гб, делается pg_dumpall чтобы переехать на более новую версию пг и на новый сервер, делается pg_dumpall, после рестора оказывается не хватает 5 юзеров и 8 счетов на оплату, хотя они были сделаны ещё 5 часов назад. С просто pg_dump выходит таже история, магическим образом не попадают в дамп 10-16 записей.
Не знаю как с выше описанным инструментом дела обстоят, но причуды бывают везде. А когда говорим ещё о базах где iowait зачастую под 80%, тк индекс существенно больше оперативной памяти, и там идёт сложный запрос с джойнами, то многие способы бэкапа могут вообще поставить бд раком, и проблема в статье автора, что по факту пользы она не несёт никакой, кроме рекламы инструмента, который даже не ясно как себя ведёт на нагруженных бд, а не где 2 кб данных.
Не говоря уже про то, что использование cron в 2020 году уже в принципе так себе затея и лучше использовать systemd-timer, который в отличии от крона имеет нормальные отчёты и нормально мониторится.
Приведу пример, есть бд, размер 30 гб, делается pg_dumpall чтобы переехать на более новую версию пг и на новый сервер, делается pg_dumpall, после рестора оказывается не хватает 5 юзеров и 8 счетов на оплату, хотя они были сделаны ещё 5 часов назад. С просто pg_dump выходит таже история, магическим образом не попадают в дамп 10-16 записей.
Не знаю как с выше описанным инструментом дела обстоят, но причуды бывают везде. А когда говорим ещё о базах где iowait зачастую под 80%, тк индекс существенно больше оперативной памяти, и там идёт сложный запрос с джойнами, то многие способы бэкапа могут вообще поставить бд раком, и проблема в статье автора, что по факту пользы она не несёт никакой, кроме рекламы инструмента, который даже не ясно как себя ведёт на нагруженных бд, а не где 2 кб данных.
Не говоря уже про то, что использование cron в 2020 году уже в принципе так себе затея и лучше использовать systemd-timer, который в отличии от крона имеет нормальные отчёты и нормально мониторится.
Так pg_dump — это инструмент для создания логического дампа. Его, конечно, можно использовать для резервного копирования, но это не его основное предназначение.
Ну если эти изменения приехали после старта снятия дампа, то вполне логично, что они не попали в дамп, т.к. дамп берет снапшот. Если же дамп снимался с базы, к которой не были подключены клиенты, то описанные Вами симптомы смахивают на баг.
Эту проблему решают инкрементальные бэкапы в режиме PAGE и PTRACK(про них видимо будет в следующих статьях), т.к. вычитываются только те страницы, которые поменялись со времени предыдущего бэкапа, т.е. подтребление I/O будет минимальным.
Приведу пример, есть бд, размер 30 гб, делается pg_dumpall чтобы переехать на более новую версию пг и на новый сервер, делается pg_dumpall, после рестора оказывается не хватает 5 юзеров и 8 счетов на оплату, хотя они были сделаны ещё 5 часов назад. С просто pg_dump выходит таже история, магическим образом не попадают в дамп 10-16 записей.
Ну если эти изменения приехали после старта снятия дампа, то вполне логично, что они не попали в дамп, т.к. дамп берет снапшот. Если же дамп снимался с базы, к которой не были подключены клиенты, то описанные Вами симптомы смахивают на баг.
А когда говорим ещё о базах где iowait зачастую под 80%, тк индекс существенно больше оперативной памяти, и там идёт сложный запрос с джойнами, то многие способы бэкапа могут вообще поставить бд раком, и проблема в статье автора, что по факту пользы она не несёт никакой, кроме рекламы инструмента, который даже не ясно как себя ведёт на нагруженных бд, а не где 2 кб данных.
Эту проблему решают инкрементальные бэкапы в режиме PAGE и PTRACK(про них видимо будет в следующих статьях), т.к. вычитываются только те страницы, которые поменялись со времени предыдущего бэкапа, т.е. подтребление I/O будет минимальным.
Клиенты были подключены на чтение, данные, как было написано старые, записям более 5 часов. Более подробно не распишу, т.к. доступа к серверам того клиента которому выполняли работу более нет. Руками перенесли 10 записей. Причём каждый раз не хватало разных записей, если говорим про удалить таблицы и залить заново.
Проблема ещё во времени процессора, и не всегда разрешены или будут использоваться инкрементальные бэкапы, зачастую клиент хочет полный бэкап данных раз в 1-2-4-6-8-12 часов.
Проблема ещё во времени процессора, и не всегда разрешены или будут использоваться инкрементальные бэкапы, зачастую клиент хочет полный бэкап данных раз в 1-2-4-6-8-12 часов.
Клиенты были подключены на чтение
А как это было реализовано?
Более подробно не распишу, т.к. доступа к серверам того клиента которому выполняли работу более нет. Руками перенесли 10 записей. Причём каждый раз не хватало разных записей, если говорим про удалить таблицы и залить заново.
Звучит как конкурентное обновление со стороны клиентов.
Проблема ещё во времени процессора, и не всегда разрешены или будут использоваться инкрементальные бэкапы, зачастую клиент хочет полный бэкап данных раз в 1-2-4-6-8-12 часов.
А зачем? Инкрементальный бэкап даёт все те же гарантии, что и полный.
Хм, ну не знаю как по поводу «рекламы», поделиться своим опытом это реклама? Про systemd-timer вместо крона — да пожалуйста, используйте. Я же не призываю делать один в один, но вы же поняли, что когда я говорил про крон, то речь шла о планировщике. По поводу нагруженных БД, действительно в следующих частях перейдём к режму PAGE.
Интересная штука, но ваш скрипт можно немного оптимизировать
code
inst=$1
mode=$2
status=$(
pg_probackup backup \
--instance=db1 -j 2 \
--progress -b $1 --compress \
--stream --delete-expired | awk "/$inst/&&/$mode/"'{if ($15 == "OK") print 0; else print 1}'
)
/opt/zabbix/bin/zabbix_sender -c /opt/zabbix/etc/pg.zabbix_agentd.conf -k pg.db_backup -o $statusНе видно скрипта
Отличная статья, первое знакомство прошло успешно и познавательно!
Sign up to leave a comment.
Знакомство с pg_probackup. Первая часть