LINUX.ORG.RU
ФорумAdmin

Асинхронная репликация на уровне файловой системы во время резервного копирования

 , , ,


0

3

Всем здравствуйте.

Во многих СУБД есть такая штука – называется асинхронная репликация. Это значит, что есть второй экземпляр БД (обычно на отдельном сервере, нередко в отдельном ЦОДе), называемый (в зависимости от производителя) shadow либо, простите за неполиткорректность, slave.

И вот этот slave в реальном времени получает по сети от «мастера» все журналы транзакций и применяет их к своему собственному хранилищу (в начальный момент оба хранилища синхронизированы). В результате состояние slave всегда полностью повторяет состояние «мастера» либо по окончании COMMIT’а, либо с некоторой задержкой (зависит от типа СУБД и от настройки).

А теперь вопрос.

Я, конечно, слышал про RAID 1, mdadm и вот это вот всё.

Но можно ли достичь похожего эффекта, не собирая зеркало, «как бы примонтировав» два блочных устройства в одну точку монтирования с тем, чтобы оба устройства в равной степени получили все последующие операции записи?

Конечная задача такая: хочу делать бэкап сразу на два внешних диска, чтобы состояние двух (априори чистых) ФС по окончании копирования было идентичным. Конечно, можно сделать последующий rsync с backup0 на backup1, но вот хочется обойтись как раз без него.

★★★★★

Забойная шапка, бро.

Но можно ли достичь похожего эффекта, не собирая зеркало, «как бы примонтировав» два блочных устройства в одну точку монтирования с тем, чтобы оба устройства в равной степени получили все последующие операции записи?

Но можно как-нибудь, без развода, откатить гражданское состояние обоих супругов в каком-нибудь органе регистрации гражданских состояний так, чтобы оба супруга в равной степени получили все предшествующие бракосочетанию маритальные статусы, права и обязанности?

Конечная задача такая:

А-алилуя.

хочу делать бэкап сразу на два внешних диска, чтобы состояние двух (априори чистых) ФС по окончании копирования было идентичным. Конечно, можно сделать последующий rsync с backup0 на backup1, но вот хочется обойтись как раз без него.

Идентичным на файловом уровне? Делай бэкап сразу на два блочных диска.

Идентичным на блочном уровне? Не лукавь и озвучь настоящую конечную задачу.

t184256 ★★★★★
()

Наркоман!

Ты хочешь репликацию поверх репликации? Это нормально работать не будет, и часто slave (идите нафиг со своей политкорректностью, этому термину лет больше чем SJW) будет сломан.

Монтировать удалённый диск в RAID-1? Технически это возможно, но работать это будет крайне медленно. То есть настолько медленно, что твоя база данных будет почти всегда неконсистентна.

По поводу бэкапа — ZFS поддерживает репликацию, пул (или файловая система, в зависимости от того что ты реплицируешь) будет идентичным, вплоть до опций самой ZFS. Или если надо быстро, то можно использовать инкрементальный send/recv, но уже без опций, только данные и метаданные. На солярке вроде можно инкрементально и с опциями, но я не курил — у меня нет под рукой солярки.

mord0d ★★★★★
()
Последнее исправление: mord0d (всего исправлений: 1)
Ответ на: комментарий от t184256

состояние […] ФС […] было идентичным.

на блочном уровне?

0\

Идентичным на файловом уровне? Делай бэкап сразу на два блочных диска.

Зачем? Делаешь бэкап на один (который только бэкап, чтобы данные на нём точно не изменялись), а потом оттуда размазываешь на все бэкап-машины/диски.

Ну и блочное соответствие совершенно не обязательно с современными файловыми системами.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

0\

Мало ли, может он имел в виду rsync --inplace /dev/sde /dev/sdf.

Зачем?

Ты еще конкретный набор критериев идентичности спроси. Я что, ТС что ли? Ему захотелось бэкапить реплицированием грязной базы на неправильном уровне, а я даже не понял, на каком именно неправильном уровне. Сидим, ждем реальной постановки задачи.

t184256 ★★★★★
()
Ответ на: комментарий от mord0d

Спасибо за ответ.

Не, я не про БД и не про конкретную ФС.

И диски все у меня подключены локально.

Просто мне нужен быстрый аналог операции «собрать пустое зеркало, записать в пустое зеркало, разобрать зеркало» с тем, чтобы не заморачиваться собственно с mdadm, и чтобы две половинки «зеркала» (два идентичных бэкапа) создавались в один проход (а не в два) и чтобы их можно было использовать независимо.

Bass ★★★★★
() автор топика
Ответ на: комментарий от t184256

может он имел в виду

Ну так я не просто так процитировал его текст про ФС.

Но даже если топикстартер хочет отстрелить себе яйца, зачем ему мешать и/или почему не помочь? ☺

Ему захотелось бэкапить реплицированием грязной базы на неправильном уровне, а я даже не понял, на каком именно неправильном уровне.

Очень похоже что он пока сам не знает что ему нужно. Ну или не знает конкретно как с этим всем работать.

// Если что, я без наездов и/или претензий, просто глаз резануло.

mord0d ★★★★★
()
Ответ на: комментарий от Bass

Не, я не про БД и не про конкретную ФС.

Тогда никаких конкретных советов и не будет — недостаточно вводных.

И диски все у меня подключены локально.

Тогда дешевле будет сделать так как t184256 рекомендовал — размазывать сразу на несколько дисков, чтобы не занимать процессор повтором операций.

собрать пустое зеркало, записать в пустое зеркало, разобрать зеркало

Эээ… Это так не делается.

чтобы их можно было использовать независимо

Но потом ты не сможешь собрать из них снова зеркало для синхронизации данных если в обоих томах будут разные данные, зеркалирование идёт master→slave, потому на slave данные отличные от master затрутся.

Опиши задачу нормально, с юзкейсами и желательно примерами и/или схемами, сейчас это выглядит как винегрет, который, кажется, ты сам не очень понимаешь. ☺

mord0d ★★★★★
()
Ответ на: комментарий от Bass

Я правильно понимаю, что реальная задача — бэкапить СУБД X локально на два внешних жестких диска 1) быстро 2) с гарантией иденичности при восстановлении (не на уровне файлов или структур ФС)?

t184256 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.