Помощь - Поиск - Пользователи - Календарь
Полная версия: MySQL - master - slave
Онлайн-форум hostobzor.ru > Архив (темы до 1.06.2015). Только для чтения. > Коммерческий хостинг. Общие форумы > Общие вопросы
Drug
Вопрос на засыпку, у кого есть мускульные базы на двух серверах вида мастер-слейв.
Дайте, плиз, совет не сталкивались ли вы с проблемой, что слейв за мастером обновляет данные с приличной задержкой от 1 до 15 секунд - при том что базы на обоих серверах нагружены не пиково?
Если да, то где что покрутить - в инете искал плохо поэтому ничего не нашелsmile.gif
dima2
Цитата(Drug @ 13.10.2010, 21:10) *
...в инете искал плохо поэтому ничего не нашел...

Поищите хорошо - кто вам мешает ? А если не сможете обращайтесь к консалтерам, они помогут...
Drug
Вы не поняли, искал я хорошо, но видимо не достаточно. Консалтеры мне не нужны, вполне сам в состоянии покрутить параметры, какие только вопрос?
eSupport.org.ua
Вот консалтеры и подскажут, какие именно крутить smile.gif
Admin
Ну, жлобы smile.gif))) Написали бы, что сами не знаем.
different
На канал посмотрите, может у первого сервера он просажен основным трафиком и на БД остается мало?
eSupport.org.ua
Ладно, раз пошли такие обвинения...
Итак, в mysql выполнение репликации идет через бинарные логи в один тред.
На мастере может быть выполнено несколько тредов одновременно, зависит от настроек и числа ядер CPU. Соответственно, если это происходит постоянно, то и имеем пресловутое постоянное отставание.
Проверить это можно через Seconds_Behind_Maste, там указано, на сколько именно идет отставание.
Еще возможно, что нагрузка банально высокая, это будет видно по Slave_IO_State. Если там пусто - значит проблема одного треда. Если занято - высокая нагрузка. Что характерно - и то и другое легко вылечить вертикальным масштабированием и наращиванием пропускной мощности между серверами.
Лично я бы посоветовал начать крутить с установки munin и по дисперсии значений графиков определить узкое место - сеть/диск/процессор.
Кошелек для оплаты: Z399249487492
Жлобам платить не обязательно wink.gif
Drug
Мне на другом форуме уже дали похожий ответ
Код

Репликация накатывается в один поток, поэтому, если на мастере у Вас
работало несколько потоков одновременно, на реплике они выполняются
последовательно, приводя к отставанию. Также надо понимать, что если
какой-то один запрос выполняется на мастере 15 секунд, то и на реплике
он будет выполняться 15 секунд, что, очевидно, тоже отображается как
пятнадцатисекундная задержка реплики.


5 YE ушло

Диска на слейве быстрее и лучше чем на мастере. Так что скорее всего дело в потоках

Спасибо.
eSupport.org.ua
Пользуйтесь mysql-proxy для решения подобных проблем
Drug
уже про него почитал на досуге, но ведь проблему репилики он не решит - или он сам в место реплики будет создавать две одинаковые копии базы ?
eSupport.org.ua
Да
Drug
поставил 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 - не помогло

в чем косяк может быть?
eSupport.org.ua
Самому скрипт писать надо
Drug
Цитата(eSupport.org.ua @ 20.10.2010, 19:30) *

Самому скрипт писать надо

А до готового пока никто не додумался? Или мы такие первые у кого проблема с задержкой в 800 секунд между мастером и слевом (слейв быстрее чем мастер)
eSupport.org.ua
Додумались конечно
Но вот что-то делить его ни с кем не хотят, жлобы наверное wink.gif
Drug
А знаете таких лично? smile.gif
Admin
Цитата(Drug @ 21.10.2010, 13:16) *

А знаете таких лично? smile.gif

Самое время протестировать:
http://forum.hostobzor.ru/index.php?showforum=94

smile.gif
sergeybezzub
А смысл тогда в чем у прокси если он не может писать на два бекэнда, а репликация master-slave у нас идет с задержкой в 800 секунд

Только что разве для селектов на базы. но это сделать нет возможности если репликация тормозит
eSupport.org.ua
Правильно, надо писать свой синкер, как это сделали в ispsystem (oproxy).
Это текстовая версия — только основной контент. Для просмотра полной версии этой страницы, пожалуйста, нажмите сюда.
Русская версия Invision Power Board © 2001-2024 Invision Power Services, Inc.