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

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

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

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

На самом деле, более простым решением было бы попытаться добавить 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

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

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

• Все ваши записи (ВСТАВКИ, ОБНОВЛЕНИЯ, УДАЛЕНИЯ) происходят в 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-masters под управлением Galera . Это облегчает настройку mysql multi-master, и вам будет легче «полу» автоматически масштабировать.

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

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

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

Intel 311 серии 20GB SLC SSD ($ 120 каждый) будет выполнять работу блестяще.

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