Вопрос или проблема
У меня есть кластер высокой доступности с двумя узлами, узел один является основным, а узел 2 – его зеркалом. У меня проблема с ресурсом mysql, так как мои узлы не синхронизированы.
обзор drbd
Главный узел:
0:home Подключен Основной/Вторичный Актуально/Актуально C r—–
1:storage Подключен Вторичный/Основной Актуально/Актуально C r—–
2:mysql Автономный Вторичный/Неизвестно Актуально/Устаревший r—–
Вторичный узел:
0:home Подключен Вторичный/Основной Актуально/Актуально C r—–
1:storage Подключен Основной/Вторичный Актуально/Актуально C r—–
2:mysql Автономный Основной/Неизвестно Актуально/Устаревший r—–
Просматривая файл сообщений, я нашел следующее:
Apr-19 18:20:36 clsstd2 kernel: block drbd2:self C1480E287A8CAFAB:C7B94724E2658B94:5CAE57DEB3EDC4EE:F5887A918B55FB1A bits:114390101 flags:0
Apr-19 18:20:36 clsstd2 kernel: block drbd2:peer 719D326BDE8272E2:0000000000000000:C7BA4724E2658B94:C7B94724E2658B95 bits:0 flags:1
Apr-19 18:20:36 clsstd2 kernel: block drbd2:uuid_compare()=-1000 by rule 100
Apr-19 18:20:37 clsstd2 kernel: block drbd2:Не связанные данные, прерывание!
Apr-19 18:20:37 clsstd2 kernel: block drbd2:conn (WFReportParams -> Отключение)
Apr-19 18:20:37 clsstd2 kernel: block drbd2:ошибка при получении ReportState, l: 4!
Apr-19 18:20:38 clsstd2 kernel: block drbd2:асендер завершен
Apr-19 18:20:38 clsstd2 kernel: block drbd2:Завершение потока асендера
Apr-19 18:20:38 clsstd2 kernel: block drbd2:Соединение закрыто
Apr-19 18:20:38 clsstd2 kernel: block drbd2:conn (Отключение -> Автономный)
Apr-19 18:20:39 clsstd2 kernel: block drbd2:приемник завершен
Apr-19 18:20:39 clsstd2 kernel: block drbd2:Завершение потока приемника
Apr-19 18:20:39 clsstd2 auditd[3960]: Дебетовый демон вращает журналы
Я не понимаю, в чем проблема и как я могу ее решить, так как проверив оба узла, я понял, что в директории var/lib/mysql у меня нет файла ibdata1 на узле 2, но он существует на узле 1.
Проблема в том, что вы столкнулись с “знаменитым” состоянием разделенного мозга DRBD, в результате чего оба узла DRBD перешли в состояние “Автономный”. Трудно сказать, есть ли у вас действительная или поврежденная база данных на вашем основном узле, но у вас сейчас есть два пути на выбор:
- Попробуйте снова синхронизировать узлы DRBD, назначив один из них как имеющий более новую версию данных, что не обязательно в вашем случае.
Вот что вы запускаете на втором узле:
#drbdadm secondary resource
#drbdadm disconnect resource
#drbdadm -- --discard-my-data connect resource
Вот что вы запускаете на активном узле, который, как вы думаете, имеет самую свежую версию данных:
#drbdadm connect resource
Если это не поможет, вы можете уничтожить второй узел и имитировать автоматическое восстановление, выполнив эту команду:
#drbdadm invalidate resource
- Очистите данные обоих узлов с помощью последней команды из (1) и восстановите свою базу данных из резервных копий.
Надеюсь, это помогло!
П.С. Я действительно рекомендую избегать использования DRBD в производственной среде. То, что вы видите, довольно распространенная проблема, к сожалению.
Проблема здесь в Не связанные данные, прерывание!, которое вы видите в журналах. Вероятно, что узлы меняли роли достаточно раз, когда были отключены, и историческая генерация, указанная в метаданных, больше не совпадает. Смотрите Руководство пользователя DRBD здесь для получения дополнительной информации: https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/#s-gi
На этом этапе вам нужно выбрать узел для перезаписи данных другого и выполнить новую полную синхронизацию. Для этого вы должны восстановить метаданные на узле, который будет SyncTarget. Вы можете сделать это с помощью drbdadm create-md <resource>
Решением было восстановление метаданных путем выполнения следующих команд на узле, где я хотел их вновь сгенерировать. Теперь все снова синхронизировано.
drbdadm down resource
drbdadm wipe-md resource
drbdadm create-md resource
drbdadm up resource
drbdadm disconnect resource
drbdadm connect resource
Последняя команда выполняется сначала на узле, где восстанавливаются метаданные, а затем на другом узле.
Ответ или решение
Решение проблемы с узлами DRBD, находящимися в состоянии StandAlone
Введение
Ваша ситуация с кластером высокой доступности (HA) и DRBD (Distributed Replicated Block Device) знаменует собой распространенную проблему, называемую "разделённый мозг" (split brain). Эта проблема возникает, когда оба узла кластера теряют связь друг с другом и независимо изменяют свое состояние, что приводит к несоответствию данных.
Описание проблемы
Исходя из вашего описания, можно легко заметить, что один из ресурсов, связанный с MySQL, оказался в состоянии StandAlone на обоих узлах. Это состояние указывает на то, что узлы не могут синхронизировать свои данные, что, в свою очередь, вызывает проблему с потерей целостности базы данных.
- Ваша конфигурация показывает, что на узле node 1 присутствует файл
ibdata1, а на узле node 2 он отсутствует. Это сигнализирует о том, что база данных на узле 1 может быть более актуальной, тогда как на узле 2 может отсутствовать значительная часть данных.
Анализ логов
Логи показывают следующее сообщение: Unrelated data, aborting!. Это означает, что на узлах присутствуют данные, которые больше не синхронизированы, и система DRBD решила прервать соединение, чтобы предотвратить возможную потерю данных.
Решение проблемы
Для исправления проблемы вам необходимо выбрать, какой узел будет "директировать" процесс синхронизации, а какой будет его "целевым" узлом. Ниже приведены шаги, которые вам необходимо предпринять:
1. Регенерация метаданных на узле с более актуальными данными.
Следуйте этим шагам на узле, который, по вашему мнению, содержит более свежие данные (в данном случае, предположительно, node 1):
# drbdadm down ресурс
# drbdadm wipe-md ресурс
# drbdadm create-md ресурс
# drbdadm up ресурс2. Подключение и синхронизация узлов.
Выполните команду connect на каждом узле. Сначала запустите её на узле, где вы создавали метаданные, а затем на втором узле:
# drbdadm disconnect ресурс # выполните на обоих узлах
# drbdadm connect ресурс # сначала на узле с активными метаданнымиАльтернативные пути решения
Если предыдущий метод не сработал, у вас есть ещё несколько вариантов:
-
Полная перезагрузка данных: Можно полностью стереть данные на одном из узлов и восстановить базу данных из резервной копии. Этот вариант подходит, если данные на первичном узле не являются актуальными.
-
Использование опции
--discard-my-data: Если вы уверены в актуальности данных на одном узле, вы можете выполнить последовательность команд на узле, который вы воспринимаете как жертву:
# drbdadm secondary ресурс
# drbdadm disconnect ресурс
# drbdadm -- --discard-my-data connect ресурсЗаключение
Проблема с состоянием StandAlone в DRBD может быть предупреждением об отключении сетевых подключений и разногласиях в данных. Важно помнить о регулярном резервировании для большинства критических систем. Убедитесь также в правильной конфигурации класса и мониторинга сети, чтобы такие ситуации возникали как можно реже.
Обратите внимание на документацию и рекомендации разработчиков, чтобы усовершенствовать вашу систему DRBD и избежать подобных инцидентов в будущем.