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 проводился скриптом:
перед его выполнением выполнялся truncate
Тесты 2 — 4
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
"
Ваши мысли?
Итак, есть задача, облегчить жизнь 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
"
Ваши мысли?