|
|
Задавайте вопросы, мы ответим
Вы не зашли.
поставил Mysql Proxy
так его стартую
/usr/local/libexec/mysql-proxy --admin-address=a.a.a.a:4041 --proxy-address=a.a.a.a:3306 --proxy-backend-addresses=b.b.b.b:3306 --proxy-backend-addresses=c.c.c.c:3306 --daemon --pid-file=/var/run/mysql-proxy.pid
заранее на двух базах на разных серверах сделал одинакового юзера и базу
через прокси создаю таблицу на c.c.c.c:3306 она появляется, на b.b.b.b:3306 ни разу.
Версия прокси вот:
mysql-proxy 0.8.0
glib2: 2.22.4
libevent: 1.4.13-stable
lua: Lua 5.1.4
LUA_PATH: /usr/local/lib/mysql-proxy/lua/?.lua
LUA_CPATH: /usr/local/lib/mysql-proxy/lua/?.so
== plugins ==
admin: 0.7.0
proxy: 0.7.0
дебаг лог ошибок не пишет:
Код
2010-10-20 18:50:16: (message) mysql-proxy 0.8.0 started
2010-10-20 18:50:16: (debug) chassis-limits.c:75: current RLIMIT_NOFILE = 118000 (hard: 118000)
2010-10-20 18:50:16: (debug) chassis-limits.c:79: trying to set new RLIMIT_NOFILE = 8192 (hard: 118000)
2010-10-20 18:50:16: (debug) chassis-limits.c:87: set new RLIMIT_NOFILE = 8192 (hard: 118000)
2010-10-20 18:50:16: (message) proxy listening on port a.a.a.a:3306
2010-10-20 18:50:16: (message) added read/write backend: b.b.b.b:3306
2010-10-20 18:50:16: (message) added read/write backend: c.c.c.c:3306
2010-10-20 18:50:38: (debug) abs wait-for-event::done usec= 0
2010-10-20 18:50:38: (debug) abs lua-exec::done usec= 0
2010-10-20 18:50:39: (debug) abs wait-for-event::done usec= 0
2010-10-20 18:50:39: (debug) abs lua-exec::done usec= 0
2010-10-20 18:50:40: (debug) abs wait-for-event::done usec= 0
2010-10-20 18:50:40: (debug) abs lua-exec::done usec= 0
2010-10-20 18:51:35: (debug) abs wait-for-event::done usec= 0
2010-10-20 18:51:35: (debug) abs lua-exec::done usec= 0
2010-10-20 18:51:35: (debug) abs wait-for-event::done usec= 0
2010-10-20 18:51:35: (debug) abs lua-exec::done usec= 0
2010-10-20 18:51:36: (debug) abs wait-for-event::done usec= 0
2010-10-20 18:51:36: (debug) abs lua-exec::done usec= 0
Пробовал заюзать rw-splitting.lua - не помогло
в чем косяк может быть?
Неактивен
MySQL прокси все запросы передает на один из бэкэндов. Запросы на запись также передаются на один из бэкэндов, но не на оба сразу.
Неактивен
А смысл тогда в чем у прокси если он не может писать на два бекэнда, а репликация master-slave у нас идет с задержкой в 800 секунд
Только что разве для селектов на базы. но это сделать нет возможности если репликация тормозит!
Неактивен
Вы слишком много требуете от MySQL Proxy - он создавался как инструмент отладки, а только потом в силу популярности стал применяться для других задач. Может быть можно что-то с ним сделать для решения вашей задачи, но полноценным средством репликации он все равно не будет из-за отсутствия гарантий надежности при его использовании.
Неактивен
Очень большие у Вас задержки в репликации. Может, понять, почему они такие,
и сделать так, чтобы реплика не отставала?
Ну и кластер позволяет делать синхронную запись, так что в некоторых ситуациях
он вовсе не плох.
Неактивен
Как кластер даже в варианте мастер-мастер может сделать синхронную запись? или вы не про это?
Задержки такие потому что на мастере 8 ядер и там в много потоков идут запросы. на слейв идут в один поток - вот и выходит такая задержка
Неактивен
По кластером имеется в виду ndbcluster. Все операции в нем осуществляются синхронно.
Если слейв медленнее мастера, то ситуацию сделать синхронной невозможно - если потребуете синхронность, мастер тоже начнет работать со скоростью слейва. Это все равно, что отправить в дорогу автомобиль и велосипед в одной колонне. Подумайте над апгрейдом слейва, 8 ядер сейчас не бесконечно дорого.
Неактивен
я же писал слейв мощьнее чем мастер и там уже давно 8 ядер и 16 гиг памяти и SAS диски
Неактивен
Ну, раз Вы не хотите рассказывать, почему у Вас отстает реплика, давайте я расскажу
кусочек теории, может, он натолкнет Вас на какие-то размышления.
Реплика сама по себе догоняет обычно очень быстро. Единственный минус репликации —
в том, что она работает последовательно. То есть если на мастере работало 1000 запро-
сов параллельно, то на реплике они будут выполняться последовательно, что может выз-
вать отставание.
Вторым распространенным поводом внезапного отставания реплики является наличие
на мастере очень длинных обновлений. Например, если на мастере запрос выполнялся
в течение 2 часов, то, когда он добирается до реплики, реплика понимает, что отстает
от мастера по крайней мере на 2 часа (которые ей нужны для выполнения этого запроса),
о чем Вам и сигнализирует. От второго повода может спасти binlog_format=binary, ко-
торый может выплюнуть лишь небольшое (если оно небольшое) количество строк, которые
нужно изменить в результате больших вычислений на мастере. Т.е. догонять будет легче.
Но если Вы хотите, чтобы мы как-то попробовали помочь — Вам нужно таки рассказать,
почему реплика отстает (да, посмотреть на запросы, на которых отстает, понять, что
происходит).
Неактивен
Кстати, на эту тему буквально вчера писал Барон:
http://www.mysqlperformanceblog.com/201 … plication/
Но из рабочих решений, боюсь, что если Вы действительно упираетесь в однопоточность
(проверьте!), будет шардирование. Но только правда убедитесь, что это параллельность.
Очень часто достаточно аккуратно посмотреть на запросы и понять, как можно улучшить
производительность до состояния, когда реплика отстает на допустимое время.
Неактивен
да там реально паралельность потмоу как как одновремнно в онйлане тянет около 9 тысяч юзеров которые все делают одно и тоже а база с которой они работают порядка 25 гиг на диске вот и выходит что куча одновремнный похожих действий на большой базе
Неактивен
Тогда только шардирование. Ну или какой-то свой механизм репликации писать.
Неактивен
