Назад | Перейти на главную страницу

MySQL Multi-Master Replication против MySQL Cluster

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

У меня есть 4 тестовых сервера, которые я могу посвятить экспериментам. Изначально я планировал сделать мультимастер, но потом немного прочитал о MySQL Cluster. У меня есть несколько вопросов:

  1. Только ОЗУ MySQL Cluster? В брошюре говорится, что дисковые таблицы поддерживаются, но даже в их собственной документации иногда говорится, что это не так. Я хочу пережить отключение электричества.

  2. MySQL Cluster дает мне лучшую надежность по сравнению с несколькими мастерами? Меня беспокоит отключение электроэнергии, из-за чего моя установка с несколькими мастерами безнадежно рассинхронизируется. Возможность плавного восстановления после отключения электроэнергии или другого сбоя - моя основная причина, по которой я рассматриваю что-то иное, чем использование нескольких мастеров.

  3. Есть ли способ использовать временные таблицы? Мое приложение использует несколько временных таблиц, но я вижу, что MySQL Cluster их не поддерживает. Есть ли иной способ решения проблемы, кроме использования постоянных таблиц, как если бы они были временными?

  4. Могу ли я в любое время добавлять и удалять узлы данных? Без перерыва в обслуживании?

Чтобы ответить на ваши вопросы (на них, кстати, тоже есть ответы в руководстве).

  1. MySQL Cluster (ndb) постоянно хранит все индексы в памяти. Его структуры данных и шаблоны доступа оптимизированы для этого случая. Их также можно (при желании) записать на диск. Неиндексированные данные могут храниться на диске и при необходимости будут считываться (и кэшироваться). В общем, для базы данных хорошо иметь достаточно памяти для хранения рабочего набора в памяти, но кластер немного строже.
  2. MySQL / Oracle рекламирует MySQL Cluster как надежность 99,999%. Имейте в виду, что большая часть надежности не в программном обеспечении, а в среде. Если ваш коммутатор или питание перестают работать, весь кластер может выйти из строя. MySQL Cluster имеет неплохие подпрограммы, чтобы оставаться работоспособными и синхронизироваться, если узел выходит из строя и возвращается. сделать это правильно в MMR - немного сложнее, но это тоже можно сделать.
  3. Per 1. MySQL Cluster хорошо работает с данными в ОЗУ, поэтому, вероятно, вы можете использовать ndb и для них. В качестве альтернативы, в зависимости от актуальных данных и варианта использования, вы, вероятно, можете хранить временные таблицы независимо на разных серверах MySQL. Обратите внимание, что есть тесты (в то время как тесты всегда врут), показывающие, что ndb толще, чем таблицы памяти.
  4. Да, последняя версия кластера MySQL позволяет оперативно изменять конфигурацию узла и даже оперативно изменять структуры таблиц. И то, и другое сложнее с MMR.

Сказав все это хорошо о кластере MySQL, я все же хочу отметить следующее: MySQL Cluster имеет некоторые ограничения, например, выполнение операций JOIN в кластере MySQL в настоящее время очень медленное. В следующей версии это будет исправлено (ищите «проталкивающие соединения»), поэтому вы должны быть осторожны при настройке и провести несколько тестов, прежде чем переходить к кластеру, чтобы увидеть, соответствует ли это вашим потребностям.