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

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

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

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

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

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

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

Источник

1 ответ

Решение

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

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

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

Источник
Другие вопросы по тегам