Пожалуйста подождите

mysql-proxy разбор под мелкоскопом

24 июля 15:50
Рейтинг +0+0,2 - +    Эмоции
комментариев: 1
mysql-proxy — практически идеальное решение для тех, кому нужен дешевый шардинг без переписывания приложений, а также хостинг провайдерам, которым сложно контролировать криворуких клиентов :) но хотелось бы вынести mysql или снизить нагрузку на СУБД без лишних контактов с клиентами.

Итак, есть задача, облегчить жизнь mysql серверу. Доступное решение — master-slave репликация. Всё замечательно, когда у нас есть программисты, которые могут переписать приложение на использование нескольких серверов СУБД, но как быть, если таковых нет? Тут на помощь нам приходит mysql-proxy. Работая прозрачно для клиента, mysql-proxy умеет проксировать запросы нескольких slave & master серверов.

Опущу в данном топике разворачивание master-slave репликации, документации море, рекомендую только пропускать ту, которая советует копировать файлы таблиц, опция --master-data в mysqldump давно уже присутствует.

Итак, была развернута master-slave репликация с одним мастером и тремя слейвами. Задача, проверить оверхед mysql-proxy и поддержку failover.

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

Производилось несколько тестов.

Тест 1 — вставка в БД
а) напрямую в БД (результат берется за 100%) — 100%
б) через mysql-proxy (один мастер) — 69%

Тест 2 — выборка из БД
а) напрямую из БД (результат берется за 100%) — 100%
б) через mysql-proxy (только один слейв) — 75%

Тест 3 — выборка из БД
а) напрямую из БД (результат берется за 100%) — 100%
б) через mysql-proxy (три слейва) 70%

Тест 4 — выборка из БД
а) напрямую из БД (результат берется за 100%) — 100%
б) через mysql-proxy (два из трех слейвов были погашены для проверки failover) 8%

График:


Тестовые скрипты вызывались
ab -n 1000 -c 1 скрипт
и ab -n 1000 -c 10 скрипт
между вызовами была минутная пауза, отбрасывались крайние значения, среднее для коннекта без mysql-proxy бралось за 100%

Тест 1 проводился скриптом:
<?php
for ($i = 1; $i <= 1000; $i++) {
$link = new mysqli(«localhost», «login», «pass», «base»);
$link->query(«INSERT INTO test `SET`...»);
mysqli_close($link);
}
?>


перед его выполнением выполнялся truncate

Тесты 2 — 4
<?php
for ($i = 1; $i <= 1000; $i++) {
$link = new mysqli(«localhost», «login», «pass», «base»);
$q=$link->query(«SELECT * FROM `test`»);
while($r=$q->fetch_assoc()) {
print_r($r);
}
mysqli_close($link);
}
?>


Bыводы:
Если тест1 вопрос не вызывает, а тест 2 и 3 в случае сложных запросов и использования индексов будут совершенно другими при реальной нагрузке и тоже понятны, то результаты теста 4 меня немного в недоумение вводят.

Конфиг mysql-proxy в тесте4

cat /etc/default/mysql-proxy
ENABLED=«true»
OPTIONS="
--proxy-address=localhost:3309
--proxy-read-only-backend-addresses=workserver1:3306
--proxy-read-only-backend-addresses=downserver1:3306
--proxy-read-only-backend-addresses=downserver2:3306
--proxy-backend-addresses=workserver1:3306
--proxy-skip-profiling
"

Замечания:
1) коннект к мусклу вызывался каждый раз специально чтобы посмотреть на этот параметр;
2) если коннект вынести за предел цикла, то ситуация не сильно меняется;
3) в тесте 3 ситуация будет совершенно иная в рабочей ситуации, так как оверхед mysql-proxy будет перекрываться за счет шардинга
Метки mysql