nikolay
34 диска NL-SAS диска по моему оптимально поделить на 4-е vdev и два диска в качестве spare
nikolay
можно конечно сделать 2 vdev по 17, но имхо это с точки зрения перформанса не айс..
nikolay
один vdev совсем не катит, если расшириться потребуется и с точки зрения производительности
Ivan
интересно, кстати. если пересчитать сколько места 4 raidz2 vdev будет давать под данные и сколько raid10 на 34 диска + 2 spare
nikolay
больше я думаю. зеркало половину скушает. но мы не о том) почему при попытке добавить спары мне система выдает какой-то бред?
Ivan
может там шутник какой русскую о в названии датасета вставил ?
nikolay
я только что пул пересобрал, возможно конечно пошутить над собой, но не до такой степени)
nikolay
интересно, что выдаст система при попытке добавить zil на ssd..
Ivan
попробуй указать вместо названия пула диск из пула
nikolay
zil добавил без проблем.
Ivan
да
Ivan
уже не помню как я spare добавлял. вопросов у меня это не вызывало. а вот когда хотел заменить сбойный диск, вот такое поведение меня удивило. требуется не пул указать, а диск в пуле.
nikolay
по моему оба диска которые я пытаюсь добавить в качестве spare имеют таблицу разделов.. почищу ка я залоговки у них..
nikolay
да, таблица разделов мешала.. еще страньше)) почему в моем случае ключ -f не помогал?
Владимир
Всем привет. Появилась необходимость делать бекапы очень большой БД mysql. И пришла в голову мысль с бекапом через ZFS. ТО есть делать снапшот, а потом этот снапшот бекапить, ну и собственно удалять его потом. Думаю суть всем ясна. На сколько я понимаю способ не совсем корректный для мускуля, но в целом это будет схоже с ситуацией если муускуль кикнули или дёрнули по питанию, ну то есть поидее проблем быть не должно. Но всё же интересен личный опыт, кто бекапит мускуль через снапшот ZFS и были ли с этим проблемы?
George
Всем привет. Появилась необходимость делать бекапы очень большой БД mysql. И пришла в голову мысль с бекапом через ZFS. ТО есть делать снапшот, а потом этот снапшот бекапить, ну и собственно удалять его потом. Думаю суть всем ясна. На сколько я понимаю способ не совсем корректный для мускуля, но в целом это будет схоже с ситуацией если муускуль кикнули или дёрнули по питанию, ну то есть поидее проблем быть не должно. Но всё же интересен личный опыт, кто бекапит мускуль через снапшот ZFS и были ли с этим проблемы?
примерно так, тут ребята не плохо описали нюансы https://habr.com/ru/company/citymobil/blog/492172/
George
особенно на мой коммент с их ответами можно обратить внимание https://habr.com/ru/company/citymobil/blog/492172/#comment_21388832
Владимир
примерно так, тут ребята не плохо описали нюансы https://habr.com/ru/company/citymobil/blog/492172/
спасибо за ссылку, изучу
nikolay
Подморозить базу перед созданием снапшота
George
как раз рассматривается вопрос "что будет если БД не останавливать"
nikolay
Неконсистентный снапшот)
nikolay
База может потребовать доп. Телодвижений для запуска после восстановления. Например у оракла это откат на консистентное состояние через redolog
Владимир
да это я понимаю
Владимир
ну это если её не выключать
Владимир
перед снапшотом
Владимир
примерно так, тут ребята не плохо описали нюансы https://habr.com/ru/company/citymobil/blog/492172/
я пока читаю статейку, всегда круто сначала оценить чужой опыт, а далее решать какие варианты тестировать стоит, а какие сразу мимо
Ivan
чем репликация не нравится ?
Владимир
Тем что она не нужна?)
d
Всем привет. Появилась необходимость делать бекапы очень большой БД mysql. И пришла в голову мысль с бекапом через ZFS. ТО есть делать снапшот, а потом этот снапшот бекапить, ну и собственно удалять его потом. Думаю суть всем ясна. На сколько я понимаю способ не совсем корректный для мускуля, но в целом это будет схоже с ситуацией если муускуль кикнули или дёрнули по питанию, ну то есть поидее проблем быть не должно. Но всё же интересен личный опыт, кто бекапит мускуль через снапшот ZFS и были ли с этим проблемы?
Если бэкапить только изменения то объём данных будет не так велик чтобы снэпшотами это делать
Александр
Всем привет. Появилась необходимость делать бекапы очень большой БД mysql. И пришла в голову мысль с бекапом через ZFS. ТО есть делать снапшот, а потом этот снапшот бекапить, ну и собственно удалять его потом. Думаю суть всем ясна. На сколько я понимаю способ не совсем корректный для мускуля, но в целом это будет схоже с ситуацией если муускуль кикнули или дёрнули по питанию, ну то есть поидее проблем быть не должно. Но всё же интересен личный опыт, кто бекапит мускуль через снапшот ZFS и были ли с этим проблемы?
Если железа много, а консистентность и беспрерывность важны, то (а) делаешь слейв (б) реплицируешь на него (в) останавливаешь слейв и его клонируешь. В принципе, можно посмотреть всякие штуки типа xtrabackup, и сделать на их базе.
Но тут все зависит от того, сколько у тебя ресурсов на обеспечение процесса и чем ты рискуешь, если снятый снапшот запустится не мгновенно/не вполне корректно
Andrew
Тем что она не нужна?)
Тут прикол в том, чтобы бэкапить реплику, не трогая производственную базу.
d
Тут прикол в том, чтобы бэкапить реплику, не трогая производственную базу.
БД вообще не бэкапят таким путём, проблёмы себе наживаете
d
Делойте - тем ценнее будет работа других людей, которые разгребать будут)
Александр
Тут прикол в том, чтобы бэкапить реплику, не трогая производственную базу.
Не понял, а кто мешает бэкапить реплику произвольным образом, хоть останавливая, хоть нет?
Fedor
А что мешает организовать процесс резервного копирования каким-либо из средств самой базы данных? :)
Fedor
Зависит от БД, конечно.. Но в постгресе, например, можно сказать реплике "надо, чтоб ты отставала на неделю", например
Fedor
Надо смотреть изначальные требования, и решение подбирать уже под них.
Fedor
Вдруг там нюансы, которые "типа админским" подходом не решаются.
Александр
А что мешает организовать процесс резервного копирования каким-либо из средств самой базы данных? :)
например, просадка производительности при чтении. А вообще, если мы имеем в виду рабочие бэкапы краткосрочного хранения, то стоп реплики - zfs snapshot - старт реплики - система почти идеальная
Fedor
например, просадка производительности при чтении. А вообще, если мы имеем в виду рабочие бэкапы краткосрочного хранения, то стоп реплики - zfs snapshot - старт реплики - система почти идеальная
Один из вариантов, да.
В постгресе точно могу сказать, что для формирования рабочей копии не требуется читать всю бд.
Fedor
И, всё-таки, считаю, что если уж бекапить - то бекапить как можно ближе к данным.
Fedor
Снапшоты - лишь подспорье, но не инструмент решения задачи.
Александр
Снапшоты - лишь подспорье, но не инструмент решения задачи.
Снапшоты - инструмент. У любого инструмента есть область применения. Для режима "быстро откатить на час/сутки/неделю назад" снапшот - вообще идеален. Особенно учитывая, что у нас может быть база с примерно бесконечным временем полного бэкапа.
Fedor
Снапшоты - инструмент. У любого инструмента есть область применения. Для режима "быстро откатить на час/сутки/неделю назад" снапшот - вообще идеален. Особенно учитывая, что у нас может быть база с примерно бесконечным временем полного бэкапа.
Если данные и вал находятся на одном объекте зфс - тогда да. Я ж говорю - надо границы задачи изучать.
Александр
Если данные и вал находятся на одном объекте зфс - тогда да. Я ж говорю - надо границы задачи изучать.
Вообще (а) тривиальную вещь сказал (б) это не отменяет того, что 90% людей, строящих архитектуру, даже понятие "границы задачи" не осознают)
The
Блин, какая жесть про постгрес, аж кровь из глаз пошла.
Fedor
а чего с ним?
Fedor
и что тут не так?)
The
Ну, например, всё.
Fedor
ну хорошо :)
The
> надо, чтоб ты отставала на неделю
Это вот как такое?
Fedor
Задачи разные бывают)
The
> не требуется читать всю бд
Физическая репликация — это именно файловая копия БД.
Fedor
один раз снимается, и для синхры - не требуется.
The
А как вы её синхрить будете? Держать WAL за неделю?
Fedor
Архивирование вала обычное где-нибудь с третьем месте
The
Если для PITR и если нет RTO, то можно.
The
А в реальной жизни это обычно дофигища места, плюс очень долгий рестор.
Fedor
с RTO нюанс, да. :)
Fedor
Задачу надо смотреть! :)
The
Ну ладно, пардон за резкость.
У меня БД порой 500 ГБ логов в час пишут, а нормального СРК решения, кроме CommVault, не существует.
Fedor
Ну ладно, пардон за резкость.
У меня БД порой 500 ГБ логов в час пишут, а нормального СРК решения, кроме CommVault, не существует.
кстати, почитаю - спасибо. у меня нечто похожее.
Nikita
Господа, нужен ваш совет
Nikita
В сервере несколько контроллеров, к которым подключены диски. В прочих нодах я закидывал все диски в один пул, собирал какой-нибудь raidz3 и не испытал проблем
Nikita
Но ввиду того, что тут два отдельных контроллера - стоит ли закидывать диски в один пул? Или лучше держать два отдельных, чтобы не получить сильного штрафа в производительности?
Nikita
Pci-e шина, на одном процессоре, диски hdd
Nikita
Кэш, лог и спешиал на nvme
Nikita
Или один пул, два вдев на каждый контроллер в отдельности?
Alexandr
если контроллеры подключены правильно, то вообще без проблем
Alexandr
можете закивать в 1 пулл, если это нужно
Alexandr
никикх проблем не вылезет по перфоренсу
Alexandr
дайте модель мамки
Nikita
Один пул, один вдев?
Nikolay
В сервере несколько контроллеров, к которым подключены диски. В прочих нодах я закидывал все диски в один пул, собирал какой-нибудь raidz3 и не испытал проблем
Вообще без разницы вроде с точки зрения сколько у тебя контроллеров.
Даже наоборот, особо продвинутые делают зеркала в zfs из дисков на разных контроллерах. Если один котроллер сдохнет, то один диск точно в работе останется
Alexandr
и отметьте на скрине мамки в какие слоты они воткнуты