MySQL InnoDB через необработанное устройство в активной/пассивной топологии

https://dba.stackexchange.com/questions/117627

29-09-2020
|

Вопрос

У нас есть топология Active/Passive, в которой есть два комплекса x86 с общим необработанным хранилищем, где только один из узлов в данный момент имеет доступ к общему хранилищу (также известному как активный узел).В случае отказа активного узла пассивный узел инициирует перехват управления и становится активным узлом с доступом к общему хранилищу.Каждый узел имеет собственное хранилище загрузочного устройства с файловой системой.Однако к общему хранилищу не может быть смонтирована файловая система.

Мы заинтересованы в установке MySQL на обоих узлах, где его данные находятся в общем хранилище, а сервер работает только на активном узле.

MySQL с InnoDB может работать на необработанном устройстве., а также есть руководство по запуску MySQL в кластере, похожем на нашу топологию.Однако во втором примере у них есть файловая система, смонтированная в общем хранилище.Проблема с файловой системой вызывает серьезную озабоченность:

ib_logfile* по-прежнему требует файловой системы.Таким образом, сырая функция MySQL не совсем сырая.Пожалуйста, поправьте меня, если я ошибаюсь.Есть ли обходной путь для хранения этих файлов в необработанном хранилище?Мы можем сохранить журналы повторного выполнения (ib_logfile0, ib_logfile1) на загрузочном устройстве узла и всегда удаляйте эти файлы перед запуском сервера (поэтому у нас не будет старых файлов журналов в случае нескольких аварийных переключений).Однако это может привести к тому, что незафиксированная транзакция будет частично зафиксирована в случае сбоя в середине транзакции, что противоречит всей идее транзакций.

Есть ли еще файлы/функции, которые могут повлиять на поведение MySQL в этой топологии?

Решение

Стоит отметить, что журнал упреждающей записи InnoDB (WAL), ib_logfile*, — не единственное, для чего потребуется файловая система.У вас есть:

Системные таблицы в схеме mysql, которые, вероятно, используют механизм хранения MyISAM (.frm, .MYD, .MYI для каждой таблицы) (большинство из них теперь используют InnoDB в версии 5.7)
Файлы .frm для каждой таблицы InnoDB, даже при использовании общего системного табличного пространства (требуются метаданные таблицы)
Файлы журнала MySQL (журнал ошибок, общий журнал, двоичный журнал)
SSL-артефакты
auto.cnf (где UUID экземпляра MySQL генерируется и автоматически сохраняется)
db.opt для каждой схемы (в /<datadir>/<schema>/)
.par-файл, если вы создаете секционированную таблицу (убрано в версии 5.7).
Файлы .trn и .trg, если вы создаете триггеры.
Табличное пространство InnoDB tmp (5.6+)
Карта страницы пула постоянных буферов (ib_buffer_pool, 5.6+)

Все вышеперечисленное обычно находится в пределах каталог данных, так что пока у вас есть datadir=/some/valid/fs/path -- это также копируется (например,DRBD) или общий (например.NFS, GFS, OCFS) между двумя узлами — тогда все будет в порядке.

Стоит отметить, что файлы .frm, .par, .trn, .trg и .opt исчезнут вместе с новый словарь данных.

Следите за важными объявлениями в ближайшие месяцы!:)

Мне не понятно, зачем вы используете RAW-устройство?Хотя я уверен, что у вас есть причины.:)

Удачи!

Другие советы

Техника необработанного хранения хороша только для ibdata1 с innodb_file_per_table неполноценный.

Я уже упоминал об этом пару раз

Обратите внимание на архитектуру InnoDB (изображение технического директора Percona Вадима Ткаченко)

С innodb_file_per_table отключено, данные и индексы для всех таблиц InnoDB будут помещаться в необработанное хранилище вместе с двойным буфером записи, буфером вставки, словарем данных, сегментами отката и пространством отмены.

Что касается журналов повторного выполнения, вам следует рассмотреть возможность использования небольшого блочного устройства DRBD, просто для хранения /var/lib/mysql, с ib_logfile0 и ib_logfile1 в этой папке.Таким образом, аварийное переключение будет происходить следующим образом.

Разорвите DRBD между двумя серверами
Установите состояние DRBD нового сервера на Primary/Unknown
Установите DRBD на /var/lib/mysql
Подключите необработанное устройство с помощью информации ibdata1.
service mysql start
Синхронизировать устройства DRBD
Настраивать Кардиостимулятор/Укарп службы для подготовки к следующему аварийному переключению

Я предпочел DRBD/ucarp для настройки аварийного переключения. Посмотрите мои старые посты о них

ОБНОВЛЕНИЕ 14.10.2015, 11:30 ПО ВОСТОЧНОМУ ВРЕМЕНИ

Как я уже упоминал, журналы повторного выполнения должны находиться в блочном устройстве DRBD, смонтированном на /var/lib/mysql.Что касается других важных файлов, таких как

двоичные журналы
релейные журналы
журнал ошибок
медленный журнал
общий журнал

все эти файлы должны находиться в /var/lib/mysql также.Таким образом, при отработке отказа будет перенесено все, что связано с MySQL (за исключением необработанных данных, которые находятся на его собственном диске).

ПРЕДУПРЕЖДЕНИЕ :Эта настройка не предназначена для таблиц MyISAM.Если происходит жесткий переход на другой ресурс, все открытые таблицы MyISAM до сбоя/перехода при сбое будут помечены как поврежденные и потребуют запуска. REPAIR TABLE на все влияют таблицы MyISAM.

Если все ваши таблицы созданы в InnoDB, игнорируйте это предупреждение.Если вы преобразуете оставшиеся таблицы MyISAM в InnoDB, вы можете игнорировать это предупреждение.(НЕ ПРЕОБРАЗОВАЙТЕ НИКАКИЕ ТАБЛИЦЫ MyISAM В mysql СХЕМА В InnoDB).

Лицензировано под: CC-BY-SA с атрибуция

Не связан с dba.stackexchange