СХ
кто через вал восстанавливает 100тб, или у вас 100тб изменений за день набегает?
ну вот у тебя были изменения везде 30-60 млн, как ты видишь через вал откат?
Size: a a a
2020 July 27
VP
ну у postgresql так тоже можно, архивируй walы
это не то же что я написал )
DT
ну вот у тебя были изменения везде 30-60 млн, как ты видишь через вал откат?
Отстающая реплика
DT
30-60млн это далеко не 100тб
СХ
Отстающая реплика
ну то есть то что я и предлагаю только на другом уровне, на уровне файла
СХ
и опять же, это архивация и синк раз в n времени, пока всё прочтёт, пока сравнит
DT
и опять же, это архивация и синк раз в n времени, пока всё прочтёт, пока сравнит
зачем синк раз в N часов, он постоянно наливает wal журнал с отставанием.
СХ
зачем синк раз в N часов, он постоянно наливает wal журнал с отставанием.
ну это если говорим о вал, а я писал о hp tripar
СХ
и базу переводят на старые файлы
СХ
если нужно
DT
А ок
СХ
это куда быстрее чем вал или аналоги
СХ
изменение пути и ребут
DT
изменение пути и ребут
Но только на определенное время назад можно, так?
СХ
Но только на определенное время назад можно, так?
да, но на таких сервисах есть оба способа
СХ
зависит от времени
DT
да, но на таких сервисах есть оба способа
Ну так, в случае отстающей реплики на N часов тоже достаточно сделать только ребут, ага.
Так что тут разницы нет
Так что тут разницы нет
СХ
Ну так, в случае отстающей реплики на N часов тоже достаточно сделать только ребут, ага.
Так что тут разницы нет
Так что тут разницы нет
не совсем, надо переназначат мастера, потом на n времени встаёт всё раком
СХ
по крайне мере у пг
DT
не совсем, надо переназначат мастера, потом на n времени встаёт всё раком
define N времени
изменение пути и ребут
и переназначить мастера
это равноценно.
изменение пути и ребут
и переназначить мастера
это равноценно.