В зависимости от конкретного случая вариантов может быть много:
— попытаться узнать xmin/xmax проблемных туплов с помощью pageinspect и катить PITR на него с recovery_target_inclusive = false
— откатиться на состояние до инцидента и постепенно применять WAL, периодически проверяя данные
— тупо пропарсить WAL и найти в нем деструктивную запись и катить PITR на предыдущую
Более подробно не распишу, т.к. доступа к серверам того клиента которому выполняли работу более нет. Руками перенесли 10 записей. Причём каждый раз не хватало разных записей, если говорим про удалить таблицы и залить заново.
Звучит как конкурентное обновление со стороны клиентов.
Проблема ещё во времени процессора, и не всегда разрешены или будут использоваться инкрементальные бэкапы, зачастую клиент хочет полный бэкап данных раз в 1-2-4-6-8-12 часов.
А зачем? Инкрементальный бэкап даёт все те же гарантии, что и полный.
Так pg_dump — это инструмент для создания логического дампа. Его, конечно, можно использовать для резервного копирования, но это не его основное предназначение.
Приведу пример, есть бд, размер 30 гб, делается pg_dumpall чтобы переехать на более новую версию пг и на новый сервер, делается pg_dumpall, после рестора оказывается не хватает 5 юзеров и 8 счетов на оплату, хотя они были сделаны ещё 5 часов назад. С просто pg_dump выходит таже история, магическим образом не попадают в дамп 10-16 записей.
Ну если эти изменения приехали после старта снятия дампа, то вполне логично, что они не попали в дамп, т.к. дамп берет снапшот. Если же дамп снимался с базы, к которой не были подключены клиенты, то описанные Вами симптомы смахивают на баг.
А когда говорим ещё о базах где iowait зачастую под 80%, тк индекс существенно больше оперативной памяти, и там идёт сложный запрос с джойнами, то многие способы бэкапа могут вообще поставить бд раком, и проблема в статье автора, что по факту пользы она не несёт никакой, кроме рекламы инструмента, который даже не ясно как себя ведёт на нагруженных бд, а не где 2 кб данных.
Эту проблему решают инкрементальные бэкапы в режиме PAGE и PTRACK(про них видимо будет в следующих статьях), т.к. вычитываются только те страницы, которые поменялись со времени предыдущего бэкапа, т.е. подтребление I/O будет минимальным.
Ну чудес не бывает, Вам как-то нужно принести на машину 40TB данных, какой-то постгресовой специфики в этом вопросе нет.
В зависимости от ситуации и используемого инструмента возможны различные оптимизации, которые позволяют ускорить этот процесс, например, инкрементальное восстановление в уже существующий кластер. Переиспользуя валидные страницы можно здорово сократить объем данных, который надо прокачать по сети и записать на диск, но за это придется заплатить полным перечитыванием уже имеющегося кластера.
Про Петрищево, хотя в свете возможной фейковости приказа, на котором базируется весь тезис о 'сжигании домов местного населения', это моё замечание теряет релевантность, т.к. тоже базировалось на нем.
Huawei, например, принципиально не выпускает свои акции из рук.
Это как раз логично, если речь о коллективной форме собственности.
Только основатели и работники имеют право на управление компанией и долю прибыли. И это лишает всяких условных Роттенбергов возможности стричь купоны с чужого труда.
Ну вот же:
In fact, Huawei is owned by our employees through an Employee Stock Ownership Program (ESOP) that has been in place since the beginning. No one can own a share without working at Huawei, and as of 2018 there were 96,768 shareholding employees. Our founder, Ren Zhengfei, owns a 1.14% stake in the company. https://www.huawei.com/en/facts/question-answer/who-owns-huawei
Большое спасибо за статью. Правильно ли я понимаю, что в Китае много компаний с коллективной формой собственности, например, Huawei? Если да, то где можно прочитать о том, как обычно организовано управление компанией работниками, как распределяется прибыль? Слышал краем уха про какие-то гильдии, но ни фига не понял.
Фича хорошая, но, как и инкрементальный бэкап в pgbackrest, работает на файловом уровне.
У нас есть в разработке аналогичная фича, работающая на блочном уровне: github.com/postgrespro/pg_probackup/issues/66
Нужен какой то другой более эффектный способ, что то вроде не выхода всех разрабов на места работы, это покажет что без них они никто и пусть считают стоимость простоя одного дня. На это сотни тысяч людей надо. А так донести до руководства… Несогласны… Ну и будет это решатся межь адвокатами а простой конторы и сколько инфа они конфиденциальной узнают, это другое дело
Звучит гораздо эффективнее нежели «давайте заспамим руководство служебками»
— попытаться узнать xmin/xmax проблемных туплов с помощью pageinspect и катить PITR на него с recovery_target_inclusive = false
— откатиться на состояние до инцидента и постепенно применять WAL, периодически проверяя данные
— тупо пропарсить WAL и найти в нем деструктивную запись и катить PITR на предыдущую
А как это было реализовано?
Звучит как конкурентное обновление со стороны клиентов.
А зачем? Инкрементальный бэкап даёт все те же гарантии, что и полный.
Ну если эти изменения приехали после старта снятия дампа, то вполне логично, что они не попали в дамп, т.к. дамп берет снапшот. Если же дамп снимался с базы, к которой не были подключены клиенты, то описанные Вами симптомы смахивают на баг.
Эту проблему решают инкрементальные бэкапы в режиме PAGE и PTRACK(про них видимо будет в следующих статьях), т.к. вычитываются только те страницы, которые поменялись со времени предыдущего бэкапа, т.е. подтребление I/O будет минимальным.
В зависимости от ситуации и используемого инструмента возможны различные оптимизации, которые позволяют ускорить этот процесс, например, инкрементальное восстановление в уже существующий кластер. Переиспользуя валидные страницы можно здорово сократить объем данных, который надо прокачать по сети и записать на диск, но за это придется заплатить полным перечитыванием уже имеющегося кластера.
А что такого особенного в архивных документах, что они должны пользоваться безусловный доверием?
Про Петрищево, хотя в свете возможной фейковости приказа, на котором базируется весь тезис о 'сжигании домов местного населения', это моё замечание теряет релевантность, т.к. тоже базировалось на нем.
Миф о "хато-сжигательнице" Зое базируется на сомнительных материалах:
https://p-balaev.livejournal.com/1192919.html
Вот только местных жителей из домов уже выперли оккупанты, из-за чего им срочно приходилось копать землянки
Это как раз логично, если речь о коллективной форме собственности.
Только основатели и работники имеют право на управление компанией и долю прибыли. И это лишает всяких условных Роттенбергов возможности стричь купоны с чужого труда.
Печально, если это так, такая форма собственности — это крайне прогрессивное явление.
Как акции могут принадлежать комитету? O_o Это же как если бы жилое здание принадлежало собранию жильцов, а не жильцам.
Ну вот же:
In fact, Huawei is owned by our employees through an Employee Stock Ownership Program (ESOP) that has been in place since the beginning. No one can own a share without working at Huawei, and as of 2018 there were 96,768 shareholding employees. Our founder, Ren Zhengfei, owns a 1.14% stake in the company.
https://www.huawei.com/en/facts/question-answer/who-owns-huawei
Большое спасибо за статью. Правильно ли я понимаю, что в Китае много компаний с коллективной формой собственности, например, Huawei? Если да, то где можно прочитать о том, как обычно организовано управление компанией работниками, как распределяется прибыль? Слышал краем уха про какие-то гильдии, но ни фига не понял.
Кмк, поэма не про настроение. Она про трудовое воспитание детей в коллективе на базе коллективной собственности на средства производства.
У нас есть в разработке аналогичная фича, работающая на блочном уровне:
github.com/postgrespro/pg_probackup/issues/66
С большим интересом жду ваш фидбэк =)
Мейнтейнер pg_probackup на связи =)
А какие опции показались своеобразными? Как Вы считаете, чего не хватает документации?
Звучит гораздо эффективнее нежели «давайте заспамим руководство служебками»
Попробуйте pg_probackup. Там есть DELTA режим, который не требует архива.