MySQL InnoDB Cluster – обзор кластера

Дата: 13.01.2017

Это перевод статьи Alfredo Kojima.

При работе с InnoDB кластером важно знать в каких состояниях он может находиться, как интерпретировать эти состояния и что делать для восстановления при тех или иных сбоях.

Возможные состояния ноды

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

Состояния при обращении напрямую:

• OFFLINE
• RECOVERING
• ERROR
• ONLINE

Состояния, которые видны другим нодам:

• RECOVERING
• UNREACHABLE
• ONLINE

Когда сервер MySQL запущен, но ещё не присоединился к кластеру, он находится в состоянии OFFLINE. Сразу после присоединения к кластеру состояние сменится на RECOVERING, что указывает на идущий процесс синхронизации с другими нодами кластера. При успешном завершении этого процесса, состояние меняется на ONLINE или, если по какой-то причине синхронизация не удалась, то на ERROR.

Если нода в состоянии ONLINE перестает отвечать другим частям кластера (по причине сбоя, проблем сети, высокой загруженности и т.д.), то её состояние меняется на UNREACHABLE. Если в этом состоянии она не ответит в течении определенного промежутка времени, то будет удалена из кластера и в выводе команды cluster.status() станет отображаться как (MISSING). Процесс исключения из кластера производится путем голосования и произойдет только в том случае, если количество других нод достаточно для кворума.

Возможные состояния кластера

На следующей диаграмме показано в каких состояниях может находиться кластер и как происходят переходы между ними.

Сплошными линиями показаны команды, которые мы можем выполнять через MySQL Shell при том или ином состоянии, пунктирными линиями отображаются события, вызванные не зависящими от нас внешними обстоятельствами.

Для удобства восприятия некоторые возможности не показаны на схеме. Например, вы можете выполнять большинство команд подобных addInstance() или rejoinInstance() в любом состоянии, пока есть кворум.

Команда cluster.status() может показывать следующие состояния кластера:

• OK - отображается, когда все ноды находятся в состоянии ONLINE, и и есть достаточно избыточности, чтобы без потерь выдержать отказ по крайней мере одной из них.
• OK_PARTIAL - когда одна или более нод недоступны, но избыточности всё её достаточно, чтобы перенести по крайней мере её один отказ.
• OK_NO_TOLERANCE - когда количество нод в состоянии ONLINE достаточно для кворума, но нет избыточности. Кластер из двух нод не имеет запаса прочности. Если одна из них перейдет в состояние UNREACHABLE, другая не сможет сформировать большинство, что приведет к простою в работе базы данных.
• NO_QUORUM - одна или более нод в состоянии ONLINE, но их количество недостаточно для кворума. В этом случае кластер становится недоступным для записи, будут выполняться только запросы на чтение.
• UNKNOWN - означает, что вы выполняете команду status() на ноде, которая находится в состоянии отличном от ONLINE или RECOVERING. Попробуйте подключиться к другой ноде.
• UNAVAILABLE - это состояние показано на схеме, но не возвращается командой cluster.status(). В этом случае все ноды кластера находятся в состоянии OFFLINE. Они могут работать, но не являться частью кластера. Например, это может произойти, если все ноды перезагружены без rejoining.

Разделение кластера

Редкий сценарий, который может быть непонятным и опасным, это разделение кластера на 2 или более части. Например, такое может произойти, если ноды расположены в различных местах, и произошел отказ сети между ними. В этом случае все ноды могут быть в состоянии ONLINE, но члены одной группы будут выглядеть как UNREACHABLE для другой и наоборот. Для сохранения целостности базы данных, обновления сможет принимать только один кусок кластера, тот в котором больше половины нод.

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

Восстановление после сбоев

Ниже приведены 3 наиболее распространенные ситуации, которые могут возникнуть в случае отказа. Будут даны рекомендации по их идентификации и по действиям, которые потребуется выполнить для восстановления, используя InnoDB cluster API в консоли MySQL Shell.

Перезапущенный сервер

Если mysqld был по какой-то причине перезапущен (авария, переконфигурация и т.д), то он не вернется в кластер автоматически. Необходимо в явном виде дать ему указание на возвращение в кластер. Это можно сделать с помощью команды cluster.rejoinInstance(), которая в качестве параметра принимает URI экземпляра.

Например: cluster.rejoinInstance("root@192.168.1.50")

Потеря кворума

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

Чтобы разблокировать оставшуюся в меньшинстве часть кластера, нужно его перенастроить, дав указание учитывать только те ноды, которые в данный момент находятся в состоянии ONLINE, и игнорировать остальные. Для этого используется команда cluster.forceQuorumUsingPartitionOf() с URI одной из ONLINE нод в качестве параметра. Все остальные ноды, которые видны как ONLINE для указанной, будут добавлены в переопределенный кластер.

Например: cluster.forceQuorumUsingPartitionOf("root@192.168.1.30")

Обратите внимание, что это опасная команда. Как указывалось ранее, если мы имеем ситуацию разделения кластера, то мы можем случайно создать split-brain (несколько изолированных частей кластера, каждая из которых ведет себя как полный кластер), что приведет к рассогласованию данных. Перед использованием команды убедитесь, что UNREACHABLE ноды действительно находятся в состоянии OFFLINE.

Все ноды в OFFLINE

Команда cluster.forceQuorumUsingPartitionOf() требует, чтобы наш кластер состоял хотя бы из одной ноды в состоянии ONLINE. Если получилось так, что все ноды находятся в состоянии OFFLINE, то восстановить кластер можно только повторно выполнив “bootstrap” из одной ноды. Для этого используйте команды dba.restoreFromCompleteOutage() на ноде, определенной как источник кластера, и rejoinInstance() на всех прочих.

Заключение

MySQL InnoDB кластер предназначен для того, чтобы сделать High Availability доступной для всех пользователей MySQL независимо от уровня знаний и опыта работы. Важно знать как интерпретировать показания команды cluster.status(), позволяющей мониторить состояние кластера. Теперь вы знаете когда и какие действия необходимо предпринимать, чтобы ваши базы данных MySQL продолжали оптимально функционировать.

Посмотрите обновленное руководство о том как запустить InnoDB Cluster.

© Все права на данную статью принадлежат порталу SQLInfo.ru. Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в бумажных изданиях допускается только с разрешения редакции.