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

Как масштабировать mySQL с большим количеством серверов баз данных (скажем, 20 серверов баз данных)

Масштабирование с 1 сервера базы данных MySQL до 4-5 серверов очень ясно из документации официального сайта разработчика MySQL: http://dev.mysql.com/doc/refman/5.1/en/replication-solutions-scaleout.html

А как насчет масштабирования с 4 серверов до 20 серверов? мы просто добавляем его в качестве мази? Имеется в виду 19 подчиненных и только 1 главный? Это означает, что скорость вставки будет одинаковой независимо от того, сколько серверов БД мы вставим.

Есть ли лучший способ горизонтального масштабирования для MySQL, при котором чем больше серверов мы устанавливаем, тем выше скорость чтения и записи. Мы видим, что это необходимо, потому что это система для компаний с крупными сделками (торговый сайт)

О да, по возможности избегайте хранения SAN. Если требуется SAN, можно также перенести MySQL на Cassandra.

Проверьте кластеризацию mysql-mmm или ndb, если вы имеете дело с таким количеством узлов, однако имейте в виду, что если вы действительно используете MySQL Cluster (ndb), вам нужно будет соответствующим образом изменить свой код.

MySQL-MMM можно найти по адресу http://mysql-mmm.org/ и материал ndb является частью MySQL Cluster Server с mysql.com

Есть несколько решений.

Чтобы получить производительность вставки бога с минимальным влиянием на ваш код, взгляните на кластеры mysql. Они выходят далеко за рамки репликации и прозрачно реализуют сегментирование. Я считаю (но нужно копать, чтобы проверить), что кластер mysql может действовать как мастер в репликации master / slave. Так, например. у вас может быть 4-узловой кластер, обрабатывающий записи, реплицируемые на дюжину или около того ведомых устройств.

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

Если у вас сложная схема, вы можете получить большие преимущества, используя механизм объединенного хранилища для разделения данных, хотя mysql не всегда оптимизирует запросы настолько, насколько это возможно в этом сценарии.

Вам обязательно стоит посмотреть на mysqlproxy или какой-то другой уровень абстракции, если вы идете по большинству этих маршрутов.

Возможно, вы захотите изучить настройку мастера распространения.

Это потребует создания подчиненного устройства (называемого мастером распределения), которое имеет три (3) характеристики:

  • log-bin включен
  • log-slave-updates Включено
  • Каждая база данных (кроме information_schema и mysql) имеет только таблицы BLACKHOLE

Что хорошего в этом?

Представьте себе этот сценарий

  • 26 экземпляров MySQL
    • ServerA - это Мастер записи
    • ServerB - мастер распространения
    • ServerC ... ServerZ - это ведомые устройства для чтения ServerB

Вот что происходит, когда INSERT выполняется в ServerA

  • ServerA записывает запись для INSERT в свой текущий двоичный журнал
  • Поток ввода-вывода ServerB импортирует INSERT из двоичного журнала ServerA
  • Поток ввода-вывода ServerB записывает INSERT в свои журналы реле
  • Поток SQL ServerB считывает INSERT из журналов реле.
  • ServerB обрабатывает SQL
  • ServerB записывает запись для INSERT в свой текущий двоичный журнал
  • ServerB передает INSERT из своего двоичного журнала в журнал ретрансляции ServerC ... ServerZ

Это дает следующие преимущества

  1. ServerA (Мастер записи) не зависает при выполнении задач репликации
  2. ServerB (Мастер распространения) не хранит данные локально. Он предоставляет только канал для передачи двоичных записей журнала всем считывающим ведомым устройствам. Таким образом, нет тяжелых операций ввода-вывода при записи.

Это пробовали другие. Фактически, я ответил на вопрос кому-то в DBA StackExchange и Переполнение стека. Это жизнеспособный вариант для тех, кто хочет выполнять работу, но имеет приличное распределение операций ввода-вывода для чтения между двумя или более подчиненными устройствами.

Если вас беспокоит высокая доступность, не проблема. У вас есть два варианта:

ОПЦИЯ 1

Повторите настройку следующим образом

  • 26 экземпляров MySQL
    • ServerA является активным мастером записи
    • ServerB - пассивный мастер записи
    • ServerC - мастер распространения
    • ServerD ... ServerZ - это ведомые устройства для чтения ServerC
    • ServerA и ServerB - пара круговой репликации
    • Резервное копирование данных может быть выполнено в ServerB

ВАРИАНТ 2: Используйте MySQL и DRBD

Внедрить избыточность на уровне дисков через DRBD и Ucarp

  • 26 экземпляров MySQL
    • ServerA - это DRBD Primary с MySQL, работающим как Write Master
    • ServerB является вторичным DRBD с MySQL Down
    • ServerB предоставляет реплику объема данных ServerA на уровне диска.
    • Запустите ucarp для DB VIP, указывающего на DRBD Primary
    • ServerC является мастером распространения, мастер которого является основным сервером DRBD.
    • ServerD ... ServerZ - это ведомые устройства для чтения ServerC