zizop May 20 2010 at 14:16

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

2 min

1.5K

Lumber room

+10

Comments 21

miolini May 20 2010 at 14:32

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

zizop May 20 2010 at 14:39

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

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 May 20 2010 at 14:43

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

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

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

zizop May 20 2010 at 14:52

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

miolini May 20 2010 at 14:56

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

ITdirector May 20 2010 at 16:09

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

zizop May 20 2010 at 16:22

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

svetasmirnova May 20 2010 at 17:21

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

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

zizop May 20 2010 at 18:22

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

zizop May 20 2010 at 18:22

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

svetasmirnova May 20 2010 at 18:30

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

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

zizop May 20 2010 at 19:15

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

svetasmirnova May 20 2010 at 19:51

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

zizop May 20 2010 at 22:51

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

svetasmirnova May 20 2010 at 23:48

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

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

Merlyel May 21 2010 at 07:22

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

svetasmirnova May 21 2010 at 14:44

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

zizop May 21 2010 at 19:08

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

Merlyel May 21 2010 at 07:33

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

zizop May 21 2010 at 14:35

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

WellWisher Apr 25 2013 at 18:49

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