РЖ
pg_basebackup с правильными ключами, чтобы сохранить согласованность данных.
Size: a a a
2020 June 02
РЖ
Ну или любую другую систему резервного копирования.
G
т.е. делать бэкапы, передавать бэкапы по сети, ресторить бэкап?
AN
Если у вас ZFS, то есть вариант делать снапшот, пока база B в состоянии реплики, затем промоутить, и работать с ней. Вечером откатываться на снапшот и догоняться валами и так по кругу
МШ
Alexander Nikitin
Если у вас ZFS, то есть вариант делать снапшот, пока база B в состоянии реплики, затем промоутить, и работать с ней. Вечером откатываться на снапшот и догоняться валами и так по кругу
Не надо на базах вообще, а ПГ-шных особенно играться со снимками файловых систем - это гарантированный путь к "приключениям" на ровном месте.
AN
да ладно? :)
AN
На оракле всё нормально годами работало по этой схеме, никаких проблем не было, а тут, значит будут?
МШ
Ты можешь гарантировать, что снимок учитывает состояние кешей ФС, как минимум? Кеши СУБД он точно не учитывает.
AN
останавливаешь базу, делаешь снапшот поднимаешь базу
МШ
Alexander Nikitin
На оракле всё нормально годами работало по этой схеме, никаких проблем не было, а тут, значит будут?
Это потому что я не брался за оракел в такой схеме. :)
МШ
Alexander Nikitin
останавливаешь базу, делаешь снапшот поднимаешь базу
Нет у тебя возможности стопить БД, 24x7, однако
AN
это не 24 на 7, это отдельная реплика
всем привет подскажите, что означает данный процесс, из за него не уходит на рестарт база.
в логах шлет:
2020-06-02 12:28:45.343 +06 [29884] FATAL: terminating connection due to administrator command
2020-06-02 12:28:45.668 +06 [8019] FATAL: the database system is shutting down
в логах шлет:
2020-06-02 12:28:45.343 +06 [29884] FATAL: terminating connection due to administrator command
2020-06-02 12:28:45.668 +06 [8019] FATAL: the database system is shutting down
AN
понятно, что боевую БД никто никогда не стопал (за исключением запланированных даунтаймов) но иметь два стэндбая - один боевой, на который можно переключиться, а второй саппортовый, на ZFS, с которого пересоздаётся 100500 баз данных и который как хочешь так и можешь перезапускать никто не запрещает.
YS
Доброго времени суток. Есть 3 базы (A, B, C). Нужно каждую ночь синхронизировать базу B с базы A, и раз в неделю синхронизировать базу С также с базы А. То есть при синхронизации изменения в B и С не учитываются, и их данные не нужно сохранять. Какие решения есть?
А это кластеры баз (instance) PostgreSQL целиком, или именно базы (внутри одного кластера, возможно)?
РЖ
Yaroslav Schekin
А это кластеры баз (instance) PostgreSQL целиком, или именно базы (внутри одного кластера, возможно)?
Надо называть вещи прямо: кластер, который инстанс, который создаётся утилитой initdb :)
YS
Ты можешь гарантировать, что снимок учитывает состояние кешей ФС, как минимум? Кеши СУБД он точно не учитывает.
Кстати — это неважно. Главное, чтобы сам кластер БД (и все tablespaces) и WAL были в одной FS, и "снимались" одномоментно.
И это обязано работать для любой ACID СУБД, иначе бы в ней не работало и восстановление после power loss.
И это обязано работать для любой ACID СУБД, иначе бы в ней не работало и восстановление после power loss.
G
Yaroslav Schekin
А это кластеры баз (instance) PostgreSQL целиком, или именно базы (внутри одного кластера, возможно)?
Первое
A
Ребят привет.
А по проблеме RETURNING и партиционирования никаких изменений?
Все так же добавлять триггер на удаление записи из мастер таблицы?
PG11
А по проблеме RETURNING и партиционирования никаких изменений?
Все так же добавлять триггер на удаление записи из мастер таблицы?
PG11