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

Способы автоматического масштабирования серверов MySQL?

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

Какие-либо предложения? заранее спасибо

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

http://toblender.com/?s=memcached

Чтобы решить проблему слишком большого количества записей, наиболее распространенным решением является добавление памяти к серверу (больший рабочий набор может храниться в ОЗУ), размещение вашей БД на более быстрых дисках (твердотельные накопители - хорошее решение, но дорогое) или сегментирование (что дорого в дополнительных серверах и сложности).

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

Вам следует подумать об использовании Звездная топология

Вот что я предлагаю

  • Один мастер записи (он же WM)
  • Один Мастер распределения (он же DM)
  • Пять (5) ведомых серверов чтения (также известных как RSS)

Подготовьте такую ​​топологию

Шаг 01: Настройте 5 RSS с этими общими параметрами

[mysqld]
skip-innodb
key_buffer_size=1G

Это приведет к тому, что все таблицы будут созданы, загружены как MyISAM Storage Engine.

Шаг 02: Настройте DM и все серверы RS

  • mysqldump схема всех таблиц из WM в файл schemadump
  • загрузить файл schemadump в DM и все 5 RSS
  • запустить ALTER TABLE tblname ROW_FORMAT=Fixed; на всех таблицах в RSS
  • запустить ALTER TABLE tblname ENGINE=BLACKHOLE; на всех столах в DM
  • только данные mysqldump (с использованием --no-create-info) в базу данных
  • загрузить датадамп во все 5 RSS

Шаг 03: Настройка репликации из DM на все 5 RSS

Шаг 04: Настройка репликации из WM в DM

КОНЕЦ НАСТРОЙКИ

Вот как работает ваш механизм чтения / записи

  • Все ваши записи (INSERT, UPDATE, DELETE) происходят в WM
  • SQL записывается в двоичные журналы DM (в DM нет фактических данных)
  • Каждый RSS является ведомым устройством чтения для DM
  • Все ваши чтения происходят в RSS

Теперь вот загвоздка ...

  • Сначала вы используете RSS 1-4 для чтения
  • Используйте 5-й RSS, чтобы активировать другие RSS
    • Ты бежишь service mysql stop на 5-м RSS
    • Раскрутите еще один RSS
    • Скопируйте / var / lib / mysql и /etc/my.cnf 5-го RSS-канала в только что созданный RSS-канал.
    • Ты бежишь service mysql stop на 5-м RSS
    • Ты бежишь service mysql stop в новом RSS

Вы можете использовать RSS # 5, чтобы запускать новые серверы снова и снова

Кстати, не используйте XEROUND для WM или DM, потому что они не поддерживают механизм хранения InnoDB или BLACKHOLE.

Надеюсь, эти идеи помогут.

Это в стойке, которую вы контролируете, или в облаке? 12 ГБ - это очень небольшая база данных относительно размера доступных дисков. Поместите его на массив RAID1 или RAID10 небольших твердотельных накопителей SLC, и ваша задержка записи исчезнет.

В Твердотельный накопитель Intel серии 311, 20 ГБ, SLC (120 долларов за штуку) отлично справятся со своей задачей.

Если бы база данных была больше, вы могли бы добиться столь же впечатляющих результатов, переместив свою базу данных в цель iSCSI на сервере ZFS SAN (построенном на стандартном серверном оборудовании с использованием Nexenta, OpenIndiana, FreeNAS или что-то еще) и настроив зеркало аналогичных SSD для ваш ЗИЛ записывает кеш. Во всех случаях, кроме самых необычных, Gigabit Ethernet более чем достаточно для перемещения трафика iSCSI базы данных.

Если вы используете Innodb, вам следует учитывать Mysql с несколькими мастерами управляется Галера. Это упрощает настройку mysql multi-master и должно упростить вам «полуавтоматическое» масштабирование.

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

Я предполагаю, что вы "настроили" файлы конфигурации mysql, например, выделенную соответствующую память и т. Д.