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

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

  • Я пробовал использовать Amazon RDS Multi-AZ, но для обновления базы данных 12 ГБ требуется около 15 минут с некоторыми минутами простоя. Это очень помогло, когда я уже знал, что в какой-то конкретный момент произойдет всплеск трафика.
  • Я также рассмотрел Xeround. Это, вероятно, лучшее решение, хотя оно довольно дорого для баз данных такого размера. Во всяком случае, это не вариант, потому что мне по закону нужна база данных в Европейском Союзе.
  • Я читал о Scalr, но не уверен, может ли это быть полезным и как.
  • Я видел, что многие провайдеры облачного хостинга предлагают решения для вертикального масштабирования, которые, я думаю, имеют время простоя 0 (не уверен, насколько это возможно, насколько я знаю, они используют гипервизор Xen). Это может быть решением, но мне интересно, если оно не имеет времени простоя и как конфигурация MySQL (и многое другое в ОС) может обновляться также без простоев.
  • Я пытался с подчиненными серверами MySQL, но это не помогло вообще.
  • Я использую memcache, который очень помогает, но этого недостаточно. Мне нужно обновить из-за записи, а не только из-за чтения.

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

Источник

4 ответа

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

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

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

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

Источник

Вы должны рассмотреть возможность использования топологии звезды

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

Подготовьте подобную топологию

Шаг 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

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

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

  • Все ваши записи (ВСТАВКИ, ОБНОВЛЕНИЯ, УДАЛЕНИЯ) происходят в 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, чтобы раскручивать новые серверы снова и снова

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

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

Источник

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

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

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

Источник

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

Твердотельный накопитель Intel SLC SSD емкостью 20 ГБ (120 долл. Каждый) отлично справился бы с этой задачей.

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

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