На написание этого поста меня натолкнул топик glix. Итак вкратце:Amazon теперь предоставляет сервис отказоустойчивой масштабируемой базы данных, т.е. наш MySQL теперь в облаке. Более подробно можно прочитать в самой статье, так что пересказывать её не буду.
Единственный минус подобного решения — цена. Не скажу, что услуги Amazon заоблачно :) дороги, но при работе сервера 24 часа в сутки, это может влететь в копеечку. Сидя на DevConf'е у меня родилась идея, как этого можно избежать.
Решение
Есть два сервера БД, первый — назовем его «default» — это наш сервер, к которому обращаются frontend'ы, второй «cloud» — тот самый облачный MySQL-сервер. Задача: при повышении нагрузки на основной сервер БД, включать облачный, синхронизировать его с основным и потом перенаправлять SQL-запросы на него.
Система будет работать в 4х режимах.
Default
Режим использования основного БД-сервера. При превышении нагузки больше порогового значения(max) определенный промежуток времени(max-timeout), задаваемого в параметрах, система переходит в состояние SyncCloud
SyncCloud
Режим синхронизации с cloud-сервером.
- Включаем облачный сервер БД, через запрос к API Amazon RDS.
- Ждем загрузки сервера
- Подключаем его как slave к основному серверу.
- Проводим рекпликацию на slave.
- Блокируем запросы на запись к мастеру.
- Проводим репликацию еще раз. Это необходимо сделать, чтобы не блокировать мастера сразу, для того, чтобы не было большого времени блокировки базы.
- Отключаем cloud-сервар от мастера. Выключаем mysqld на основном сервере.
- Включаем mysl-proxy на default-сервере, который будет пробрасывать все запросы на cloud-сервер.
Cloud
Режим работы с cloud-сервером.
В этом режиме default-сервер делает проксирование запросов к cloud-серверу. На основном сервере в это время снижается нагрузка, и после того, как она составит значение ниже порогового(min) определенный промежуток времени(min-timeout) система переходит в состояние SyncDefault
SyncDefault
Режим синхронизации с default-сервером.
- Запускаем mysqld на свободном порту(не 3306, т.к. там у нас сидит сейчас mysql-proxy).
- Подключаем default-сервер, как slave к cloud-серверу.
- Проводим репликацию на default-сервер
- Блокируем запись на cloud-сервер
- Проводим повторную репликацию
- Выключаем mysql-proxy
- Перевешиваем mysqld-сервер на default на стандартный порт(3306), который освободил mysql-proxy.
- Отправляем запрос на выключение cloud-сервера через API Amazon RDS
Итоги
В результате получаем масштабируемость за счет облачного сервера и экономию, за счет использование его только в нужные моменты.
Очень интересует мнение хабровчан насчет жизнеспособности такой схемы. Вообще видятся огромные перспекивы в этой области, особенно если удасться запустить MySQL на кластере на базе Ubuntu Enterprise Cloud(Eucalyptus)
Ссылки
- Amazon Offers MySQL in the Cloud
- Oracle продолжит развивать MySQL и создаст Cloud Office
- MySQL Enterprise for Amazon EC2
- Joyent Accelerator for MySQL
Заявляют, что у них «Speed – 3X more Transactions per Second than MySQL on Amazon EC2.» Сам не проверял пока. - Cloud Computing Framework for XAP
