Масштабирование решений для MySQL (Репликация, Кластеризация)

Правовая оговорка: Я не использовал MySQL Cluster, таким образом, я только иду от того, что я услышал.

MySQL Cluster является HA (высокая доступность) решение. Это быстро, потому что это - все в памяти, но это - реальный коммерческий аргумент, доступность. Нет никакой единой точки отказа. С репликацией, с другой стороны, если ведущее устройство спускается, необходимо на самом деле переключиться на копию, и может быть небольшое количество времени простоя. (хотя решением DRBD является другая альтернатива, которая имеет высокую доступность)

, Кластер требует, чтобы Ваша вся база данных уместилась в памяти. Это означает, что каждая машина в кластере должна иметь достаточно памяти для хранения всей базы данных. Таким образом, это не выполнимое решение для очень больших баз данных (или по крайней мере это - очень дорогое решение).

я думаю это, если HA не супер важен (чтение: вероятно, не), это - больше стычки (и деньги), чем это стоит. Репликация является чаще лучшим способом пойти.

Редактирование: я забыл упоминать также, что Кластер не позволяет внешние ключи и располагается, сканирования медленнее, чем на других механизмах. Вот ссылка, которая говорит [приблизительно 110] Известные Ограничения MySQL Cluster

Существуют некоторые хорошие дискуссии о том, как люди, которые поддерживают drupal.org, структурировали свои серверы баз данных:

• блог
• Dries Buytaert блог

WorkHabits Оба с 2007, таким образом, Кластеризирующаяся поддержка может быть более сильной теперь, но в то время, когда они выбрали репликацию.

Прохладная вещь о выполнении репликации состоит в том, что это легко. Просто настройте 2 mysql поля, измените serverID на втором поле, и затем укажите на второе поле на первое использование ведущего устройства изменения для управления.

Вот является соответствующее демонстрационное ведомое устройство my.cnf конфигурацией

#
#       Log names
#

log-bin=binlog
relay-log=relaylog
log-error=errors.log

#
#       Log tuning
#

sync_binlog = 1
binlog_cache_size = 1M

#
#       Replication rules (what are we interested in listening for...)
#
#       In our replicants, we are interested in ANYTHING that isn't a permission table thing
#

replicate-ignore-db =      mysql
replicate-wild-ignore-table=mysql.%

#
#       Replication server ID
#

server-id      =        2

, Так удостоверьтесь, что каждое ведомое устройство увеличило serverID 1 (поэтому следующее ведомое устройство является сервером 3)

, настраивает имя пользователя и пароль, который ведомое устройство может соединить на, Затем выполнить ведущее устройство изменения к MASTER_HOST = 'x.x.x.x'; измените ведущее устройство на MASTER_PASSWORD = "xxxxx";

и так далее.

наконец, выполненный "запускают ведомое устройство";

прибывает Ваше ведомое устройство и начинает копировать. сладкий ха!

Это предполагает, что Вы запускаете с 2 пустых серверов. Тогда можно вывести дб в главный сервер, и поскольку это загружается там, это также загрузится на ведомом устройстве.

можно проверить ведомое состояние путем выполнения:

выставочное ведомое состояние \G

Весело проводят время с ним.. легкий soooo...

Я не использовал их, но из документов я сказал бы, что репликация является предпочтительным решением, если самая большая загрузка читает из базы данных.

"В памяти" ограничение препятствует тому, чтобы мы использовали кластер MySQL для наших почти 50 ГБ данных, таким образом, мы используем DRBD плюс linux Heartbeat.

Это отчасти похоже на массив RAID между два (или больше) поля, который сохраняет базы данных / журналы / конфигурации в синхронизации (но только один сервер может быть "живым" за один раз). Обработка отказа является автоматической, использует тот же IP-адрес и является быстрой как перезапуск mysql, таким образом, это было хорошим решением для нас.

Кластер MySQL - это странное чудовище, и каждый раз, когда мы оценивали, он либо работал очень плохо, либо был ненадежным.

Его ужасно сложно настроить (вам нужно как минимум три узла, возможно, Больше). Кроме того, нет никаких условий для переключения клиентов при отказе, поэтому вы должны сделать это самостоятельно (или использовать что-то еще в качестве прокси-сервера и т. Д.).

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

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

При выполнении высокого исследования доступности я столкнулся со многими решениями, и, вероятно, в нашем случае, который был более интенсивной системой записи, я нашел кластер DRBD лучше, чем кластер NDB, как он обеспечивает больше каких-либо транзакций в секунду. Отказ

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

С разными модами по управлению транзакциями, предоставляемыми DRBD, вы можете одними, что уменьшило производительность, пострадавшего от репликации данных на уровне устройства по сети. Для надежной системы, которая не должна терять какую-либо транзакцию в случае сбоя, используя режим C, иначе пойти на B.

Я пытался перечислить некоторые из учащихся, которые я сделал во время настройки кластера DRBD в http: // www .techiegyan.com /? p = 132

Это очень хорошо работает на выделенном соединении для репликации, то есть резервных отдельных высокоскоростных интерфейсов на обоих машинах только для репликации DRBD. Сердцебиение может хорошо контролировать кластер со всеми службами один за другим I.e. IP-адреса, разделы, DRBD и MySQL.

Мне еще не обнаружить конфигурацию мастера-магистра на DRBD. Будет обновляться как и когда я получаю успех в этом.

Спасибо.