STONITH с кластером из 2 узлов DRBD/Pacemaker/Corosync

STONITH с кластером из 2 узлов DRBD/Pacemaker/Corosync

Итак, я вижу много противоречивых точек зрения на использование STONITH с кластером DRBD/Pacemaker/Corosync из 2 узлов для репликации данных MySQL. Пример, который я смог найти на Сайт кардиостимуляторакажется, отключает его, но во многих других местах говорят, что его следует оставить включенным..... Моя настройка будет состоять из 2 узлов с 2 интерфейсами, один физически подключен к другой машине, другой подключен к коммутатору. В таком случае, если у меня избыточные коммуникации, необходим ли STONITH? Если сервер потеряет оба сетевых соединения, он в любом случае не будет получать никаких данных MySQL, а когда он снова заработает, я планирую установить липкость на бесконечность, чтобы он (не должен) не пытался стать главным. В этом случае необходим ли STONITH или даже желателен?

решение1

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

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

Сделайте то же самое для всех избыточных подключений. Затем сделайте то же самое, отключив ВСЕ сетевые подключения одновременно.

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

Еще одна вещь, которую я рекомендую, пока вы тестируете это, прежде чем это будет запущено в производство: намеренно сломайте это. Сделайте что-нибудь, что приведет к рассинхронизации mysql и drbd, и узнайте, как это исправить. Запишите, что вам нужно было сделать, чтобы это исправить. Потому что гораздо лучше знать, как это сделать ДО того, как это действительно понадобится.

Связанный контент