Масштабирование MySQL в реальном времени

[miolini]

Amazon не предоставляет масштабируемый mysql. Это обычный mysql сервер.

[zizop]

Хм, я может чего-то не понимаю, но у них на сайте написано следующее:

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity while managing time-consuming database administration tasks, freeing you up to focus on your applications and business.

Пруфлинк

[miolini]

Это означает, что вы можете:

1. запускать свой mysql на instanses разной производительности (она ограничена) — нет вирт. машин с 1000 гигагерц cpu.
2. иметь несколько копий

Но тем не менее — любая репликация заставляет тратить примерно равные ресурсы, что и на мастер ноде. Не говоря уже о уровне изоляции транзакций.

[zizop]

Тогда получается, выгоднее иметь в облаке несколько mysql-серверов, скажем один мастер, и парочку слейвов, и при увеличении нагрузки на какой-либо из серверов, с помощью API добавлять ему ресурсов?

[miolini]

Именно. Только остаётся проблема. Узкое горлышко в скорости записи. Потому как в такой схеме все данные реплицируются. Это так сказать современный бич «масштабируемости» реляционных баз данных. Это из способов борьбы это шардинг. Но это изменение в коде.

[ITdirector]

Сколько времени это займет развертывание и репликация (примерно)? Если пиковая нагрузка происходит 2 часа в сутки — не получится ли, что пока сервера сообразят, что все плохо и сделают все, что нужно — пользователи уже уйдут?

[zizop]

Это очень сильно зависит от объема базы. В идеале надо периодически синхронизировать их, тогда по bin-log будет меньше смещение, и как следствие меньше данных надо будет передать между серверами.

[svetasmirnova]

Если я правильно понимаю назначение облачных сервисов типа Amazon они нужны тем людям, которые не могут себе позволить иметь простаивающие без работы дополнительные сервера.

А в вашей схеме, похоже, один из серверов всегда не обрабатывает клиентские запросы.

[zizop]

Один из серверов всегда включен, но если его не хватает, подключается второй(облачный), а первый становится прокси для него.

[zizop]

Т.е. тот, облачный, если он не нужен — выключен и не потребляет $$$

[svetasmirnova]

> Т.е. тот, облачный, если он не нужен — выключен и не потребляет $$$

А вот тут я не соглашусь: он куплен за деньги, соответственно теряет в цене == амортизируется даже пока стоит и не работает. То есть ещё как потребляет $$$

[zizop]

См. aws.amazon.com/rds/pricing/
Обратите внимание на «Price per hour», «per GB-month», «per 1 million requests».
Там оплата идет только за реальное время работы сервера.

[svetasmirnova]

Я обратила. А вас, похоже, не поняла. Вы услуги другим людям собираетесь предоставлять?

[zizop]

Ну, мы разрабатываем веб-сервис, а данные храним в реляционной БД. Сейчас я занимаюсь планированием развертывания кластера БД, вот и прикидываю лучшие варианты.

[svetasmirnova]

Просто если БД будете использовать только вы, то смысла в простаивающей машине не вижу: она же денег стоит.

А что такое, кстати, «первый становится прокси для него.»? По двум mysqld нагрузка распределяется?

[Merlyel]

А откуда возьмется простаивающая машина?
Есть настоящий сервер, который либо работает как сервер (норм режим), либо перекидывает (проксирует) запросы на второй сервер.
Второй сервер — это сервер Amazon, у которого покупается *время* работы, т.е. включил его — платишь денежки, выключил — не платишь.

[svetasmirnova]

Так второй сервер куплен на Amazon? Тогда другое дело, конечно. Я, похоже, автора несколько недопоняла.

[zizop]

Ну да. Я поэтому их назвал cloud и default.

[Merlyel]

Какой MySQL-proxy использовать собираетесь?
Какое-то время назад пытался искать, что пишут про прокси. Родной mysql-proxy довольно сильно страдает по производительности, т.е. с ним проблема может быть уже не с самим сервером БД, а именно с проксированием.
Другие прокси не отличались стабильностью.
Если дела сейчас обстоят также, то может есть смысл не включать прокси, а просто менять в конфиге базу, с которой работает веб-сервис. Тем более, что в таком случае mysql на сервере БД будет нагружен поменьше.
Плюс стоит производить анализ запросов на веб. Если там идет такое же большое количество запросов, то переключать обратно на свой сервер не следует, иначе получится передергивание туда-сюда серверов (нагрузка снизилась -> переключили на default -> нагрузка повысилась -> переключили на cloud -> нагрузка снизилась ->… и так по кругу).

[zizop]

Для этого и есть параметры, нагрузка должны держаться высокой/низкой в течении определенного времени. Про mysql-proxy да, возможно вариантом будет переключение ip в настройках, но тогда будет отсутствовать единая точка общения фронтэнд-БД.

[WellWisher]

можно ещё в качестве балансировщика использовать днс сервер