Инкрементная отправка и получение btrfs с локального на удаленный компьютер с mariadb

635
Siranee Jaraswachirakul.

У меня проблема с пошаговой отправкой и приемом btrfs с локального на удаленный компьютер.

Мой хост Lxd - это Ubuntu 16.04.3 LTS с lxd 2.0.10 и btrfs-progs v4.4

Мои 2 контейнера - это centos7 (CentOS Linux выпуск 7.3.1611 (Core) с

Btrfs-Progs-разви-4.4.1-1.el7.x86_64

Btrfs-Progs-4.4.1-1.el7.x86_64

MariaDB-LIBS-5.5.52-1.el7.x86_64

MariaDB-5.5.52-1.el7.x86_64

MariaDB-сервер 5.5.52-1.el7.x86_64

Первый контейнер mariadb centos7. (местные btrfs)

Я делаю btrfs подтом / var / lib / mariadb / mysql для хранения базы данных mariadb и делаю снимок за день

Результирующий снимок btrfs в примере с контейнером First mariadb centos7

ID 281 поколение 195 верхний уровень 5 путь mysql_201707210830

ID 288 gen 186 верхний уровень 5 путь mysql_201707220830

ID 290 gen 191 верхний уровень 5 путь mysql_201707230830

ID 292 gen 217 верхний уровень 5 путь mysql

Второй контейнер mariadb centos7. (удаленные btrfs)

Я делаю btrfs на томе / var / lib / mariadb

и отправьте снимок тома btrfs из контейнера First mariadb centos7, начиная с mysql_201707210830 и увеличивая его между mysql_201707210830 и mysql_201707220830 и увеличивая между mysql_201707220830 и mysql_201707230830

Пример полученного снимка btrfs в контейнере Second mariadb centos7

ID 270 gen 68 верхний уровень 5 путь mysql_201707210830

ID 274 gen 66 top level 5 path mysql_201707220830

ID 276 gen 71 верхний уровень 5 путь mysql_201707230830

Я начинаю тестировать результат на контейнере Second mariadb centos7 с помощью следующей процедуры (прежде всего «cd / var / lib / mariadb»).

  1. используйте команду "btrfs sub snap mysql_201707210830 mysql", затем "systemctl start mariadb", в результате все отлично работает, как и ожидалось. (после этого "systemctl stop mariadb", "btrfs sub del mysql" и "btrfs sub sync.")

    1. используйте команду "btrfs sub snap mysql_201707220830 mysql", затем "systemctl start mariadb", в результате все отлично работает, как и ожидалось. (после этого "systemctl stop mariadb", "btrfs sub del mysql" и "btrfs sub sync.")

    2. используйте команду "btrfs sub snap mysql_201707230830 mysql", затем "systemctl start mariadb" результат не такой, как ожидалось !!!! Мариадб не может начать.

Кто-нибудь, пожалуйста, помогите мне, какой шаг, что я делаю ошибку?

С уважением,

Сиранее Ярасвачиракул.

0

1 ответ на вопрос

0
Siranee Jaraswachirakul.

Со всей помощью службы поддержки btrfs. Большое спасибо за предложения от "Крис Мерфи" и "A L".

Наконец я обнаружил ошибочные шаги, которые сделали результат неверным. Инструмент для подтверждения идентичности между отправкой и получением снимка источника и получателя: «rsync -avnc / var / lib / mariadb / mysql_yyyymmddhhmm / user @ ip_destination: / var / lib / mariadb / mysql_yyyymmddhhmm /»

В субботу 12 августа 2017 года в 20:20 написал:

[root @ backuplogC7 ~] # rsync -avnc / var / lib / mariadb / mysql_201708090830 root@192.168.45.166: // var / lib / mariadb / mysql_201708090830

Вам нужен трейлинг / для первого каталога с опцией -a.

rsync -a dir dir

это не та же команда, что и

rsync -a dir / dir

Это сбивает с толку, но ваша команда пытается создать каталог mysql_201708090830 в источнике, в mysql_201708090830 в месте назначения. Вот почему все не соответствует. Чтобы это означало «содержимое», вам необходимо добавить косую черту как минимум в начало координат.

- Крис Мерфи

Я не помнил, какие шаги я допустил и сделал, что mysql получил UUID.

Основным моментом, из-за которого btrfs неправильно отправлял / получал инкремент, является то, что на текущем под томе «mysql» был «Received UUID», что должно происходить при получении на целевом сайте (Remote), но в моем случае он появился на исходном сайте (Local).

13.08.2017 12:52 siranee.ja@tpc.co.th пишет:

Привет "A L",

[root @ backuplogC7 ~] # btrfs sub show / var / lib / mariadb / mysql / var / lib / mariadb / mysql Имя: mysql UUID: 92f319c5-e132-3249-9b13-d39ee77a2b44 Родительский UUID: - Полученный UUID: 3ad033a -654c-add6-b1cbcdeaa639 Время создания: 2017-06-21 13:27:41 +0700 Идентификатор подчиненного объекта: 257 Поколение: 539 Генерация при создании: 9 Идентификатор родителя: 5 Идентификатор верхнего уровня: 5 Флаги: - Снимок (и): mysql_201708060830 mysql_201708070830 mysql_201708080830 mysql_201708090830 mysql_201708100830 mysql_201708110830 mysql_201708120830 mysql_201708130830

да, я думаю, что он получил UUID, потому что я восстановил источник из снимка mysql_201708040830 для доказательства того, что локальный снимок работал.

Как очистить полученный UUID? Что делать дальше? Вам нужно сделать снимок для чтения / записи в / var / lib / mariadb / mysql, а затем удалить старый подобъем и все его снимки.

Пример с https://github.com/digint/btrbk/blob/master/doc/FAQ.md

cd / mnt / btr_pool

mv mysubvolume mysubvolume.broken

btrfs subvolume снимок mysubvolume.broken mysubvolume

Вы можете сделать то же самое с каждым из ваших снимков и отправлять их как полные снимки (без -p).

~ A

- как рекомендуется из https://github.com/digint/btrbk/blob/master/doc/FAQ.md -

«Я получаю сообщение об ошибке: прервано:« Полученный UUID »установлен

Вы, вероятно, восстановили резервную копию с помощью send-receive и сделали ее доступной для чтения / записи с помощью набора свойств btrfs. Это плохо, поскольку все моментальные снимки и резервные копии будут наследовать этот идентичный «полученный UUID», в результате чего все эти подобъемы будут рассматриваться как «содержащие одинаковые данные».

Чтобы это исправить, создайте «правильный» снимок:

  • Это как ваше предложение для подсоба "mysql"

cd / mnt / btr_pool

mv mysubvolume mysubvolume.broken

btrfs subvolume снимок mysubvolume.broken mysubvolume

Теперь у mysubvolume должен быть пустой «Полученный UUID». Обратите внимание, что для того, чтобы иметь чистую среду, вам также необходимо исправить все подобъемы (снимки, а также резервные копии), которые вы создали с поврежденным подобъемом.

Проверьте, есть ли еще сломанные подобъемы:

btrfs subvolume show mysubvolume.broken

Список подобъемов btrfs -a -R / mnt / btr_pool | grep <"Полученный UUID" сверху>

Список подобъемов btrfs -a -R / mnt / btr_backup | grep <"Полученный UUID" сверху>

  • Похоже, что из этого руководства мне нужно очистить <"Полученный UUID"> только подобъем "mysql" и другие ("mysql_201708070830" должен использовать снимок субобъема btrfs -r вместо снимка субобъема btrfs. Это правильно?

Теперь очистите все перечисленные подобъемы (так же, как и выше, но теперь используйте btrfs subvolume snapshot -r). Затем удалите все сломанные подобъемы:

btrfs subvolume delete * .broken

Наконец, у вас должна быть чистая среда, и btrbk больше не будет жаловаться.

Последней процедурой восстановления поврежденного снимка являются следующие.

Я сделал следующее, и это работает так, как должно быть прямо сейчас.

[root @ backuplogC7 mariadb] # снимок субобъема btrfs mbroken_201708070830 rw_201708070830 Создайте снимок «mbroken_201708070830» в папке «./rw_201708070830» [root @ backuplogC7 mariadb] # btrfs. ID 257 поколения 542 пути 5-го уровня mbroken ID 317 поколения 576 пути 5-го уровня mbroken_201708070830 ID 318 поколения 568 пути 5-го уровня mbroken_201708080830 ID 319 поколения 569 пути 5-го уровня mbroken_201708090830 ID 320 поколения 570 верхнего уровня 5 пути mbroken_201708308 путь 5-го уровня mbroken_201708110830 ID 322 gen 572 путь верхнего уровня 5 mbroken_201708120830 ID 323 gen 573 путь верхнего уровня 5 mbroken_201708130830 ID 324 gen 543 путь верхнего уровня 5 mysql ID 348 gen 576 путь верхнего уровня 5 rw_201708070830 [корневая резервная копия] ма mbroken_201708080830 rw_201708080830 Создать моментальный снимок «mbroken_201708080830» ID 257 поколения 542 пути верхнего уровня 5 mbroken ID 317 поколения 576 пути верхнего уровня 5 пути mbroken_201708070830 ID 318 поколения 577 верхнего уровня 5 пути mbroken_201708080830 ID 319 поколения 578 верхнего уровня 5 пути mbroken_201708090830 ID 320 поколения 579 верхнего уровня 5 пути mbroken_201708308 путь 5-го уровня mbroken_201708110830 ID 322 gen 581 верхний уровень 5 путь mbroken_201708120830 ID 323 gen 582 верхний уровень 5 путь mbroken_201708130830 ID 324 gen 543 верхний уровень 5 путь mysql ID 348 gen 576 верхний уровень 5 путь rw_201708070830 ID 349 gen 580 уровень 530 gen 580 верхний уровень 530 top 577 top 570 level 577 top 5 350 поколение 578 путь 5-го уровня rw_201708090830 ID 351 поколение 579 путь 5-го уровня rw_201708100830 ID 352 поколение 580 путь 5-го уровня rw_201708110830 ID 353 поколение 581 путь 5-го уровня rw_201708120830 ID 354 поколение 582 путь 5-го уровня rw_201708130830 root @ mari резервная копия @ mari @ Список подобъемов # btrfs -a -R. | grep "

[root @ backuplogC7 mariadb] # список подобъемов btrfs -a -R. | grep "3ad0334a-4063-654c-add6-b1cbcdeaa639" / var / lib / mariadb / mysql_201708070830 | SSH 192.168.45.166 btrfs получает / var / lib / mariadb на subvol / var / lib / mariadb / mysql_201708070830 на subvol mysql_201708070830 [root @ backuplogC7 mariadb] # субтитр btrfs mysql_201708070830_201070703070_70_70_70_70_70_70_70_70_70_70_70_70_70_70_7070_70_70_70_70_70_70_70_70_70_70_70 -126d-574a-814c-e3b4c81b414e Родительский UUID: 1d5bb8eb-b0df-2549-8b62-552cfa517609 Полученный UUID: - Время создания: 2017-08-14 07:00:08 +0700 Идентификатор подчиненного элемента: 355 Генерация: 583 Генерация при создании: 583 ID родителя: 5 ID верхнего уровня: 5 Флаги: только для чтения Снимок (и): [root @ backuplogC7 mariadb] # rsync -avnc / var / lib / mariadb / mysql_201708070830 / root@192.168.45.166: / var / lib / mariadb / mysql_201708070830 / отправка списка добавочных файлов ./

отправлено 3773 байта получено 19 байтов 1083,43 байта / сек. общий размер 718361496 ускорение составляет 189441,32 (СУХОЙ ЗАПУСК) [root @ backuplogC7 mariadb] # btrfs send -p / var / lib / mariadb / mysql_201708070830 / var / lib / mariadb / mysql_8080 | SSH 192.168.45.166 btrfs получает / var / lib / mariadb В subvol / var / lib / mariadb / mysql_201708080830 Снимок экрана mysql_201708080830 [root @ backuplogC7 mariadb] # rsync -avnc / var / lib / mariadb70808302: 682_302_302_302_302_302_301. / var / lib / mariadb / mysql_201708080830 / отправка списка добавочных файлов ./

отправлено 3769 байт, получено 19 байт, 688,73 байт / с, общий размер - 718361496, ускорение - 189641,37 (СУХОЙ БЕЗ) [root @ backuplogC7 mariadb] # btrfs send -p / var / lib / mariadb / mysql_201708080830 / var / lib / mariadb / mysq8_80 | SSH 192.168.45.166 btrfs получает / var / lib / mariadb на subvol / var / lib / mariadb / mysql_201708090830 с моментальным снимком mysql_201708090830 [root @ backuplogC7 mariadb] # rsync -avnc / var / lib / mariadb70802302_309_309_309_309_302_301_301_301_301_301_301_301_301_301_030_30_30_30_30_30_30_30. / var / lib / mariadb / mysql_201708090830 / отправка списка добавочных файлов ./

отправлено 3773 байта получено 19 байтов 583,38 байт / сек. общий размер 718361496 ускорение составляет 189441,32 (СУХОЙ БЕЗ) [root @ backuplogC7 mariadb] # btrfs send -p / var / lib / mariadb / mysql_201708090830 / var / lib / mariadb / mys1008308 | SSH 192.168.45.166 btrfs получает / var / lib / mariadb На subvol / var / lib / mariadb / mysql_201708100830 Снимок экрана mysql_201708100830 [root @ backuplogC7 mariadb] # rsync -avnc / var / lib / mariadb70.1682308302308302308302302308302302308302302308308302308302308302302308302302308_1001301008 / var / lib / mariadb / mysql_201708100830 / отправка списка добавочных файлов ./

отправлено 3773 байта получено 19 байтов 689,45 байт / сек. общий размер 718361496 ускорение составляет 189441,32 (СУХОЙ БЕЗ) [root @ backuplogC7 mariadb] # btrfs send -p / var / lib / mariadb / mysql_201708100830 / var / lib / mariadb / mysql_81 | SSH 192.168.45.166 btrfs получает / var / lib / mariadb на subvol / var / lib / mariadb / mysql_201708110830 на снимке экрана mysql_201708110830 [root @ backuplogC7 mariadb] # rsync -avnc / var / lib / mariadb70.1682: 681302308302_302_302_302_302_301_302_302_301_302_301_302_130_130_130_130_130_130_130_130_1964_30_1964_30_1964_64_1.0_30.1_30_1.0_30.1_30_1.0_302_130_30_130_130_1.0_1.0.1.0.1.0.1.0 / var / lib / mariadb / mysql_201708110830 / отправка списка добавочных файлов ./

отправлено 3773 байта получено 19 байтов 689,45 байт / сек. общий размер 718361496 ускорение составляет 189441,32 (СУХОЙ БЕГ) [root @ backuplogC7 mariadb] # btrfs send -p / var / lib / mariadb / mysql_201708110830 / var / lib / mariadb / mysq30_201 | SSH 192.168.45.166 btrfs получает / var / lib / mariadb В subvol / var / lib / mariadb / mysql_201708120830 Снимок экрана mysql_201708120830 [root @ backuplogC7 mariadb] # rsync -avnc / var / lib / mariadb70.181202: 681_302_301_302_302_302_302_302_302_302_302_302_302_302_302_302_302_302_302_130_30_30_30_30_30_30_30_30_1. / var / lib / mariadb / mysql_201708120830 / отправка списка добавочных файлов ./

отправлено 3773 байта получено 19 байтов 689,45 байт / сек. общий размер 718361496 ускорение составляет 189441,32 (СУХОЙ БЕГ) [root @ backuplogC7 mariadb] # btrfs send -p / var / lib / mariadb / mysql_201708120830 / var / lib / mariadb / mys3083081 | SSH 192.168.45.166 btrfs получает / var / lib / mariadb В subvol / var / lib / mariadb / mysql_201708130830 Снимок экрана mysql_201708130830 [root @ backuplogC7 mariadb] # rsync -avnc / var / lib / mariadb70.130302: 6830_3030_3030_302_3030_302_302_302_302_302_302_302_30_30_30_30_30. / var / lib / mariadb / mysql_201708130830 / отправка списка добавочных файлов ./

отправлено 3773 байта, получено 19 байтов, 689,45 байта в секунду, общий размер - 718361496, ускорение - 189441,32 (DRY RUN) [root @ backuplogC7 mariadb] #