я не знаю что такое пеловая
всё!
Да, если отбросить все выполняющиеся в момент снапшота транзакции
А потом на старте ошметки транзакций будет какая нить посгря откатывать 😂
он просто буквы не выговаривает некоторые, кайтавый
Вы же просили консистентность, так это она и есть
Но если глубже копать, то надо учитывать особенности СУБД, например для mysql с innodb в каком режиме изоляции транзакций они выполняются
С каких это пор? От констстентности ещё ожидают отсутсвие Потери данных
И? Если транзакция не успела упасть на диск, а оный диск забекапили в этот момент, то будет не констстентность данных в этом бекапе
Для это дают команду СУБД на сброс буферов на диск а потом снапшот делают, что не ясно?
Да? Ну давай передай мне условной постгре в квм с хоста «команду» Для этого дампы делают и master-slave кластера если не хочется мастер грузить в проде
Ещё раз, даже если буфер СУБД не сброшен на диск, то данные в консистентном состоянии, это же ACID
Ну считайте дальше их консистентными, только потом жидко не пукайте когда штатный рекавери постгри вас на старте не выручит в очередной раз
Вы путаете консистентность и состояние СУБД в определенный момент
значит я пожертвовал информацией в пользу возвращения консистентности а это может дорого стоить конторе
Вы не понимаете что такое транзакция?
Вы не понимаете что бэкапить диски ВМ и считать это нормальным бэкапом базы - моветон?
Транзакция переводи бд из одного консистентного состояние в лругое
Ну здрааасти! Veeam бэкапит имеджем виртуалки со скулём именно так. Включается галочка app-aware бэкап, и агент дёргает приложуху, чтобы та сбросила все свои дампы, потом ФС квизится, потом снимается снапшот гипервизором. отдельным пунктом идёт бэкап транзакшен логов уже
https://t.me/srv_admins/1205972
рекавери свалился с ошибкой, все, приехали
С какой ошибкой, если там откат незавершённых транзакций?
у отката всегда два исхода
Что может быть причиной такого: PostgreSQL не может защитить вас от повреждения файловой системы или отказа жесткого диска. Используемая система хранения должна быть надежной. Жесткие диски и твердотельные накопители выйдут из строя, поэтому RAID необходим, но недостаточен для защиты. Вам нужны резервные копии и/или репликация для защиты от сбоев нескольких дисков, повреждения файловой системы и т. д. В PostgreSQL задокументированы определенные параметры, которые ослабляют гарантии безопасности при сбоях. Например, если вы установите fsync=off, вы даете PostgreSQL разрешение на уничтожение ваших данных в случае сбоя в обмен на то, что он будет работать немного быстрее. PostgreSQL гарантирует, что не сохранит незафиксированные данные, они будут потеряны, если система выйдет из строя перед транзакцией COMMIT. Операторы не окружены BEGINи COMMITдля этой цели фиксируются, когда оператор возвращается.
первый же пункт проходит по кейсу, вытаскивать виртуальный диск из под работающей постгри - дурная затея и бэкап ВМ с хоста фактически это и делает, просто от ВМ не отключает
покажите мне их в линухе с ext4 банальным без lvm, например
Вы решили усугубить
нет, я вам обьясняю что для бэкапа постгри есть специальный инструмент от авторов постгри
Его никто не отменял
Вот есть подправляют ядро и снапшоты будут работать и для ext4 https://github.com/veeam/veeamsnap
кмк это уже перебор, патчить и пересобирать ядро что бы не юзать pgdump но дай бог что бы кому-то пригодилось, авось через dkms заводится
Вам доводилось снимать часто бекапы с огромных бд без репликации?
доводилось, для этого у нас есть выделенная реплика без нагрузки в которую падают данные и оттуда можно их свободно дампить
Дочитайте вопрос до конца
Обсуждают сегодня