ArtAnt
по-моему мы про разные вещи говорили, вы про горячий снэпшот виртуалки, я про снэпшот zfs.
central
ну получается так, только если делать snapshot с RAM То тут zfs наврятли поможет
Fedor
если делается снапшот средствами зфс, но под управлением обвязки гипервизора - там это возможно.
есть даже какие-то хелперы для постгреса.
Владимир
если делается снапшот средствами зфс, но под управлением обвязки гипервизора - там это возможно.
есть даже какие-то хелперы для постгреса.
вижу слово снапшот и пострес в одном предложении, пишу)
Владимир
о чём тут речь?)
Fedor
о рисках для постгреса при использовании снапшотов :)
Владимир
Господа хорошие, кто имел опыт отката на снэпшоты, которые делаются на рабочей виртуалке каждые 15-ть минут, насколько это реально с учетом что в виртуалке работает относительно ненагруженная БД PostgreSQL на службе у 1С? Насколько такие снэпшоты потом оказываются пригодные к откату?
ну у меня не так часто, но делаю
Я посылаю постгресу чекпойнт, а потом бекаплю его. в моём случае это именно бекап, но в целом это может быть и снапшот и когда чекпойнт сделан, это рабочий бекап, проверено
Владимир
ssh root@10.0.6.18 "su - postgres -c 'psql --dbname DBNAME --command=CHECKPOINT'"
ssh root@10.0.6.7 'vzdump 120 -compress zstd -storage HDD'
Владимир
вот так делаю я, 120 это номер контейнера
Владимир
10.0.6.18 - ip контейнера
Владимир
10.0.6.7 - ip дедика
Владимир
если не делать чекпойнт, бд будетт не консистивной, будет выглядеть как-будто машину рубанули по питанию
Владимир
ну и я пробовал завести бекап без чекпойнта, он чаще не работоспособный получался
Владимир
как повезёт, с чекпойнтом всё окей
Fedor
Fedor
я рекомендую full_page_writes всё таки.
Dmitriy
все верно, бд откатится до ближайшего чекпойнта
ArtAnt
Fedor
только небезопасною
Владимир
которые или откатятся автоматом или в ручную
Владимир
это совсем не критично
Fedor
не, самое страшное будет, когда (не если, а когда) утечёт рутовый ключик.
Dmitriy
только небезопасною
почему? ПГ же при старте поймет, что его вырубили некорректно и начнет восстановление и при таком раскладе именно чекпойнт будет таковым, а если есть архив WAL, то при правильно restore_command потерь даже не будет
Владимир
не, самое страшное будет, когда (не если, а когда) утечёт рутовый ключик.
ну они не торчат в наружу
Fedor
это часто и не нужно.
Владимир
не, самое страшное будет, когда (не если, а когда) утечёт рутовый ключик.
так что утечки рутового ключика мало, нужно ещё и проебать доступы во внутреннюю сеть)
Fedor
гораздо проще, чем кажется)
Fedor
ну и славно.
Владимир
давайте не будем раздувать из мухи слона)
d
не, самое страшное будет, когда (не если, а когда) утечёт рутовый ключик.
Делал для чувствительной БД так: кидал через сохранялку WAL в gpg (есть прямо в конфиге у pg возможность прописать команду для этого), там оно открытым ключом шифровалось и падало в архив. Закрытые ключики лежали в сейфе и никогда не доставались.
Владимир
если вам не нравится такой подход, это не значит что надо искать способ докапаться, лучше предложи вариант лучше, а мы послушаем
Fedor
Владимир
psql, api
ну при малых объёмах базы возможно, с ростомэто вызывает проблемы, да и с маленькими бд так удобнее тупо
Fedor
ну и надо глянуть, можно ли там права нарезать, чтоб чекпоинт можно было без суперюзера делать
Fedor
Fedor
ладно, у тебя работает - гут. но о рисках надо, всё-таки, предупреждать.
Fedor
ну при малых объёмах базы возможно, с ростомэто вызывает проблемы, да и с маленькими бд так удобнее тупо
psql как интерфейс к постгресу, а не как средство трансляции информации
Владимир
ладно, у тебя работает - гут. но о рисках надо, всё-таки, предупреждать.
я не отрицаю эти риски, и не пойму на кой пошёл вопрос о ключах ssh, когда я просто показал пример как у меня, у себя они могут реализоватьк ак их вздумается
Fedor
кстати, для объёмов до десятков террабайт и pg_dump неплохо справляется.
Владимир
Владимир
под словом не плохо боюсь у каждого свои требования))
central
кстати, для объёмов до десятков террабайт и pg_dump неплохо справляется.
а как консистентность данных в дампе?
Fedor
относительно транзакции при подключении
Dmitriy
кстати, для объёмов до десятков террабайт и pg_dump неплохо справляется.
эм, у меня бд 12Тб, pg_dump делает это часов 8-9
Владимир
эм, у меня бд 12Тб, pg_dump делает это часов 8-9
стало понятно чего моя вишенка так ржёт?))
Fedor
эм, у меня бд 12Тб, pg_dump делает это часов 8-9
не, ну не обычный же дамп вида "админ стайл" выполнять.
Dmitriy
для меня это боль и именно поэтому zfs рассматривал для бэкапирования, но сам zfs не дает нужное количество IOPS для приложения, поэтому отказался. zfs медленный
Fedor
ага. хотя где-то видел стоечки на несколько miops
Fedor
у которых зфс внутрях
Владимир
Dmitriy
ага. хотя где-то видел стоечки на несколько miops
железные сервы отчасти решат проблему, но у меня гугловое облако )
Fedor
а, тогда да
Fedor
там даже с энтропией сложности
Fedor
а не вы ли не так давно тут проводили тесты зфс в гугл компьюте?
Fedor
с постгресом и репликацией
Dmitriy
а не вы ли не так давно тут проводили тесты зфс в гугл компьюте?
нет нея, но я наблюдал за тем чуваком
Fedor
вот интересно, чем закончилось
Dmitriy
вот интересно, чем закончилось
по сути ничем. ZFS для большой нагрузки настроить можно, но на хорошем "Железном сервере" с отдельными NVME рейдами для DATA и WAL файлов
Fedor
зато сколько потом сервисов будет от фс
Fedor
я тут лвм начинаю потихоньку считать бутылочным горлышком.
Alexander
cannot open 'draid2:4d:1s:11c': no such device in /dev
must be a full path or shorthand device name
подскажите кто сталкивался, что за ошибка?
George
George
не так ввели команду 99%
George
zpool create test draid2:4d:1s:11c /dev/sd[c-m]
версия zfs какая? если не из мастера, то draid ещё нет
ArtAnt
Доброго времени суток, кто-нибудь думал над тем, что например опция zfs_vdev_sync_write_max_active и множество ей подобных, включая на чтение и т.д. по сути не позволяют эффективно использовать разные типы носителей на одном хосте организованные в самостоятельные пулы, Т.е. если для nvme можно хоть 100 поставить и более, то в случае наличия HDD это уже может снижать производительность, а указывать отдельно для пула их нельзя. Правильный ли вывод напрашивается, что nvme, ssd, 3d-xpoin можно использовать, только как l2arc или slog в случаях когда в системе имеется хотя бы один пул состоящий из механических дисков? Т.е. можно ли однозначно утверждать, что система хранения на zfs организована неправильно (неэффективно) если одновременно присутствуют отдельные пулы, как на HDD так и на флэш памяти на одном хосте для которых выше указанные опции применяются одинаково?
Сергей
Смысл использовать SSD если HDD дешевле?
Пулы могут быть под разные цели. На одном хочет может быть пул из ссд для СУБД и пул из хдд для иных целей (бэкап, раздача статики, ...)