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