форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум WEB технологии
Изначальное сообщение		[ Отслеживать ]

"MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
Сообщение от Nas_tradamus (ok) on 23-Апр-09, 13:06
Здравствуйте! "Старт слэйва без блокировки таблиц мастера." Возможно ли это? Хочу иметь всегда работающую копию основной базы - чтобы сама синхронизировалась с мастером при восстановлении связи. Видимо, в MySQL это невозможно. Возможно ли это в PostgreSQL?
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
Сообщение от angra (ok) on 23-Апр-09, 14:50
А что не так с мускулом? Слейв помнит свою позицию в binlog и начнет работать с нее.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от Nas_tradamus (ok) on 23-Апр-09, 15:22
	>А что не так с мускулом? Слейв помнит свою позицию в binlog >и начнет работать с нее. Как я понял, для нормальной работы репликаций, позиция бинлога слэйва должна совпадать с позицией бинлога мастера. Если это не так, репликации перестают работать.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от angra (ok) on 23-Апр-09, 15:40
	Вы либо что-то не то читали, либо не так поняли. Отставание слейва от мастера это естественное явление. Неоднократно наблюдал отставание на 6, а то и 12 часов, не говоря уже о разнице в одну позицию. Из фака: Q: Does the slave need to be connected to the master all the time? A: No, it does not. The slave can go down or stay disconnected for hours or even days, and then reconnect and catch up on updates. For example, you can set up a master/slave relationship over a dial-up link where the link is up only sporadically and for short periods of time. The implication of this is that, at any given time, the slave is not guaranteed to be in synchrony with the master unless you take some special measures. Могу предположить, что у вас смешалась информация о том, как стартануть слейв в первый раз, и о его регулярной работе.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от Nas_tradamus (ok) on 23-Апр-09, 15:49
	Да, я путаюсь немного. Но про то, что слэйв всегда отстает, знал, но забыл ). В общем, у меня проблема такая: если что-то произошло со слэйвом или мастером и сбой носил длительный характер, репликацию уже невозможно восстановить - приходится лочить таблицы на мастере, делать дамп, вписывать позиции мастерлог-файла на слэйве и т.д.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от angra (ok) on 23-Апр-09, 16:10
	Есть большая разница между сбоем сети и сбоем самой репликации. В первом случае репликация без проблем продолжится при восстановлении связи. Во втором даже при идеальной связи можно сушить весла. Из практики самая частая причина сбоя репликации это какой-нибудь балбес, отдавший на слейве команду не select типа. Иногда засбоившую репликацию можно вручную поправить сделав необходимые изменения в структуре/данных и пропустив проблемный запрос. Если это не удается, то фактически приходим к варианту запуска слейва с нуля. При правильном подходе делается это достаточно просто и простой мастера может составлять доли секунды или вообще отсутствовать. От сбоя репликации по вине человека не застрахована ни одна БД, репликации постгри и оракла точно также можно угробить, дурное дело не хитрое.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от Nas_tradamus (ok) on 23-Апр-09, 16:30
	>Если это не удается, то фактически >приходим к варианту запуска слейва с нуля. При правильном подходе делается >это достаточно просто и простой мастера может составлять доли секунды или >вообще отсутствовать. Спасибо за развернутый и интересный коментарий. Не поделитесь опытом как минимизировать простой мастера до долей секунд, учитывая что каждую секунду мастер обрабатывает десятки INSERT'ов и UPDATE'ов? Где об этом можно почитать?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от angra (ok) on 23-Апр-09, 17:12
	В доке по мускулу вестимо, там очень много полезного. 1. Использовать снапшоты fs. Делаем flush tables with read lock, снапшот, show master status, unlock tables. А потом уже спокойно со снапшота переносим бинарные файлы или дамп на слейв и запускаем его с запомненной позиции. Время снятия снапшота очень мало. 2. Использовать второй слейв. Нет никакой необходимости синхронизироваться именно с мастером. Останавливаем другой слейв, снимаем позицию и базы и запускаем оба слейва.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от Nas_tradamus (ok) on 23-Апр-09, 17:18
	>В доке по мускулу вестимо, там очень много полезного. >1. Использовать снапшоты fs. Делаем flush tables with read lock, снапшот, show >master status, unlock tables. А потом уже спокойно со снапшота переносим >бинарные файлы или дамп на слейв и запускаем его с запомненной >позиции. Время снятия снапшота очень мало. >2. Использовать второй слейв. Нет никакой необходимости синхронизироваться именно с мастером. Останавливаем >другой слейв, снимаем позицию и базы и запускаем оба слейва. 1. Все-таки не миллисекунды ). Если база встанет хотя бы на 10 секунд, из соседнего кабинета сразу будут слышны гневные вопли в мой адрес :). 2. Мне бы один нормально настроить :(.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от angra (ok) on 23-Апр-09, 17:27
	>1. Все-таки не миллисекунды ). Если база встанет хотя бы на 10 >секунд, из соседнего кабинета сразу будут слышны гневные вопли в мой >адрес :). Снапшот делается _очень_ быстро, даже flush может идти дольше по времени. Ну и доли секунды начинаются все таки не с тысячных, а с десятых :) Кстати, база при локе не прекращает работу, клиенты не получают ошибок, просто запросы на какое-то время замирают. В случае нагруженной базы такое постоянно бывает и без всяких локов
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от Nas_tradamus (ok) on 23-Апр-09, 17:59
	>Снапшот делается _очень_ быстро, даже flush может идти дольше по времени. Ну >и доли секунды начинаются все таки не с тысячных, а с >десятых :) >Кстати, база при локе не прекращает работу, клиенты не получают ошибок, просто >запросы на какое-то время замирают. В случае нагруженной базы такое постоянно >бывает и без всяких локов Вот, кстати, про последнее не знал. Раньше я не умел грамотно лочить таблицы и они у меня не лочились - поэтому просто запрещал юзеру базы доступ к этой базе :). Теперь знаю, что надо делать так: FLUSH TABLES WITH READ LOCK; SET GLOBAL read_only = ON; ... SET GLOBAL read_only = OFF; UNLOCK TABLES; Спасибо большое за советы. Уже придумал как написать скрипт, который все делает, действительно, за секунды. Примерный алгоритм таков: 1. Лочим базу на мастере. 2. Делаем дамп базы с перенаправлением файла дампа сразу на слэйв-сервер по ssh. 3. Дропаем базу на слэйве, создаем новую и заполняем ее инфой из дампа. 4. Считываем в переменные название бинлога файла и позицию мастера. 5. Выставляем на слэйве соответствующие значения из этих переменных. 6. START SLAVE 6. Делаем анлок мастера.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от angra (ok) on 24-Апр-09, 01:48
	Такой вариант будет работать очень долго при большом размере баз. Дамп вообще самый медленный способ переноса, select into + load from в несколько раз быстрее, а копирование бинарных файлов еще быстрее. Ну и в любом случае приличную скорость можно получить только при использовании снапшотов, освойте LVM, это совсем не сложно.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от Nas_tradamus (ok) on 24-Апр-09, 11:21
	Увы, делать снапшоты с разделов ufs+gmirror не получается. upd. Почитал насчет SELECT INTO - в оф. мануале сказано "This method works for any kind of data file, but saves only table data, not the table structure. " (http://dev.mysql.com/doc/refman/5.1/en/backup.html)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от Nas_tradamus (ok) on 27-Апр-09, 18:02
	>Кстати, база при локе не прекращает работу, клиенты не получают ошибок, просто >запросы на какое-то время замирают. В случае нагруженной базы такое постоянно >бывает и без всяких локов Сейчас проверил - база НЕ работает, если ее залочить! Битрикс сразу же пишет "DB query error". очень жаль :(.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	14. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от angra (ok) on 27-Апр-09, 18:13
	>Сейчас проверил - база НЕ работает, если ее залочить! А у меня работает, традиционное ЧЯДНТ :) >Битрикс сразу же пишет "DB query error". >очень жаль :(. Зависит от того, какие запросы он пытается выполнить и какие значения таймаутов.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	15. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от Nas_tradamus (ok) on 28-Апр-09, 15:16
	>Зависит от того, какие запросы он пытается выполнить и какие значения таймаутов. > На клиенте таймауты не выставлены. В my.cnf: [mysqld] connect_timeout = 3500 interactive_timeout = 28800 wait_timeout = 500 delayed_insert_timeout = 500 [mysqlhotcopy] interactive-timeout Что не так, не подскажите?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от angra (ok) on 29-Апр-09, 09:47
	Никогда не приходилось трогать эти параметры. Как я уже сказал проблема в самом битриксе, а так как с ним не сталкивался, то и нужды глядеть в его код не было. Все приложения в разработке которых я участвовал абсолютно свободно переносили flush tables with read lock, хотя опять таки его время было крайне мало. Ради интереса на домашней машине попробуйте зайти в мускул с двух клиентов, в одном сделайте flush tables with read lock, а в другом попробуйте отдавать различные запросы.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от Nas_tradamus (ok) on 29-Апр-09, 10:58
	Еще раз большое спасибо за ответы на мои ламерские вопросы :). Я написал на perl скрипт, восстанавливающий упавшую репликацию, который запускается по крону каждые полчаса. Работает он всего 15-20 секунд (т.е. мастер-база в это время недоступна). Но раньше у меня репликация валилась примерно раз в 10 дней - так что, данное время простоя совсем не критично. Еще, стоит отметить, что на слэйве выставлен параметр slave-skip-errors = 1062,1053, чтобы репликация не падала по каждому чиху: а именно "Duplicate entry '%s' for key %d" и "Server shutdown in progress".
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	18. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от angra (ok) on 29-Апр-09, 16:31
	>Еще раз большое спасибо за ответы на мои ламерские вопросы :). Ничего ламерского в вопросах не было. Все строго по теме и хорошо сформулировано. Не надо путать новичка(все мы ими были) и ламера(эти ребята безнадежны).
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	19. "MySQL. Старт слэйва без блокировки таблиц мастера."	+/–
	Сообщение от Nas_tradamus (ok) on 03-Фев-11, 16:25
	> Еще раз большое спасибо за ответы на мои ламерские вопросы :). > Я написал на perl скрипт, восстанавливающий упавшую репликацию, который запускается по > крону каждые полчаса. Работает он всего 15-20 секунд (т.е. мастер-база в > это время недоступна). Но раньше у меня репликация валилась примерно раз > в 10 дней - так что, данное время простоя совсем не > критично. > Еще, стоит отметить, что на слэйве выставлен параметр slave-skip-errors = 1062,1053, чтобы > репликация не падала по каждому чиху: а именно "Duplicate entry '%s' > for key %d" и "Server shutdown in progress". Стоит отметить, что после перехода на InnoDB битрикс перестал рушиться при попытки записать сессию в таблицу при залоченной базе. Видимо, какая-то отложенная запись работает.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема