Когда отдавать предпочтение master-slave, а когда кластеризовать?
Я знаю, что было написано много статей о репликации базы данных. Поверьте мне, я потратил некоторое время на чтение тех статей, в том числе и этой, в которой объясняются плюсы и минусы тиражирования. Эта SO статья подробно описывает репликацию и кластеризацию, но не отвечает на следующие простые вопросы:
- Когда вы копируете свою базу данных и когда вы кластеризуете?
- Можно ли выполнять оба одновременно? Если да, то что вдохновляет каждого?
Заранее спасибо.
2 ответа
В настоящее время MySQL поддерживает два разных решения для создания среды высокой доступности и достижения масштабируемости на нескольких серверах.
MySQL Replication
Первая форма - это репликация, которую MySQL поддерживает с версии 3.23 MySQL. Репликация в MySQL в настоящее время реализована в виде асинхронной установки "главный-подчиненный", в которой используется логический сервер доставки журналов.
Настройка "ведущий-ведомый" означает, что один сервер назначен в качестве главного. Затем необходимо получить все запросы на запись. Затем мастер выполняет и регистрирует запросы, которые затем отправляются на подчиненное устройство для выполнения и, следовательно, для сохранения одних и тех же данных во всех членах репликации.
Репликация является асинхронной, что означает, что на подчиненном сервере не гарантируется наличие данных, когда мастер выполняет изменение. Обычно репликация выполняется в режиме реального времени, насколько это возможно. Однако нет никакой гарантии относительно времени, необходимого для распространения изменения на ведомое устройство.
Репликация может использоваться по многим причинам. Некоторые из наиболее распространенных причин включают масштабируемость, отказоустойчивость сервера и решения для резервного копирования.
Масштабируемость может быть достигнута благодаря тому, что теперь вы можете выполнять запросы SELECT для любого из ведомых устройств. Однако операторы записи, как правило, не улучшаются из-за того, что записи должны выполняться на каждом элементе репликации.
Отказоустойчивость может быть реализована довольно легко с помощью внешней утилиты мониторинга, которая использует тактовый сигнал или аналогичный механизм для обнаружения отказа главного сервера. MySQL в настоящее время не выполняет автоматическое переключение при сбое, поскольку логика, как правило, очень зависит от приложения. Имейте в виду, что из-за того, что репликация является асинхронной, возможно, что не все изменения, сделанные на ведущем устройстве, распространятся на ведомое устройство.
Репликация MySQL работает очень хорошо даже через медленные соединения и с соединениями, которые не являются непрерывными. Он также может использоваться на разных аппаратных и программных платформах. Возможно использовать репликацию с большинством механизмов хранения, включая MyISAM и InnoDB.
MySQL Cluster
MySQL Cluster - это распределенная, многораздельная система секционирования, которая использует синхронную репликацию для обеспечения высокой доступности и производительности.
MySQL Cluster реализован через отдельный механизм хранения, называемый NDB Cluster. Этот механизм хранения автоматически распределяет данные по нескольким узлам данных. Автоматическое разбиение данных позволяет распараллеливать выполняемые запросы. Таким образом, и чтение, и запись могут масштабироваться, поскольку записи могут быть распределены по многим узлам.
Внутренне MySQL Cluster также использует синхронную репликацию, чтобы удалить любую единственную точку отказа из системы. Поскольку два или более узла всегда гарантированно имеют фрагмент данных, по крайней мере один узел может выйти из строя без какого-либо влияния на выполнение транзакций. Обнаружение сбоев автоматически обрабатывается с удалением мертвого узла, прозрачного для приложения. После перезапуска узла он будет автоматически интегрирован в кластер и начнет обрабатывать запросы как можно скорее.
В настоящее время существует ряд ограничений, которые необходимо учитывать при принятии решения о том, является ли MySQL Cluster правильным решением для вашей ситуации.
В настоящее время все данные и индексы, хранящиеся в MySQL Cluster, хранятся в основной памяти по всему кластеру. Это ограничивает размер базы данных в зависимости от систем, используемых в кластере.
MySQL Cluster разработан для использования во внутренней сети, поскольку задержка очень важна для времени отклика. В результате невозможно провести один кластер на большом географическом расстоянии. Кроме того, хотя MySQL Cluster будет работать над настройками обычной сети, для достижения максимально возможной производительности можно использовать специальные кластерные межсоединения.
- В конфигурации Master-Salve операции записи выполняются Master, а Read - slave. Таким образом, все запросы SQL сначала достигают мастера, и очередь запросов сохраняется, и операция чтения выполняется только после завершения записи. Существует общая проблема в конфигурации Master-Salve, которую я также засвидетельствовал, что, когда очередь становится слишком большой, чтобы быть обслуживаемой мастером, тогда эта архитектура рушится, и ведомый начинает вести себя как мастер. Для кластеров я работал на Cassandra, где запрос достигает узла (таблицы) и поддерживается хеш коммита, который замечает различия, внесенные в узел, и обновляет другие узлы на основе этого хэша коммита. Так что здесь все операции не зависят от одного узла.
Мы использовали Master-Salve, когда данные для записи невелики по размеру и рассчитаны, иначе мы используем кластеры. Кластеры дороги в пространстве, а Master-Salve - во времени, поэтому ваше решение о том, что выбрать, зависит от того, что вы хотите сэкономить.
- Мы также можем использовать оба одновременно, я сделал это в моей нынешней компании. Мы переместили таблицы с большинством операций записи в Cassandra, и мы написали 4 API для выполнения операции CRUD для таблиц в Cassandra. Поскольку всякий раз, когда приходит HTTP-запрос, он сначала попадает на наш веб-сервер, и из кода, выполняемого на нашем веб-сервере, мы можем решить, какую операцию необходимо выполнить (среди CRUD), а затем мы вызываем этот конкретный API для внесения изменений в базу данных cassandra.