![]() |
Задавайте вопросы, мы ответим
Вы не зашли.
Есть задача иметь 2 сервера на разных хост площадках, чтобы при отключении основного, второй оставался доступен и при этом не останавливалась работа сервиса.
Отсюда у меня вопрос, если настроить репликацию и мастер сервер просто выключить из сети, будет ли слейв работать с клиентами самостоятельно? Т.е. изначально все запросы отправляются на мастер, а когда он недоступен - надо отправлять на слейв. Скушает ли он их? Я предполагаю, что не скушает и его надо будет перенастроить как самостоятельный серв. Правильно ли я мыслю?
Неактивен

Честно говоря, не понял, в чем вопрос. Если Вас устроит работоспособность сервиса
в режиме «только на чтение», то проблемы никакой нет — Вам нужно настроить обыч-
ную репликацию (и запилить права доступа на реплике, чтобы туда нельзя было пи-
сать), а потом научить ПО ходить в мастер (а в случае неуспеха — в реплику). Если
ПО учить тяжело — можно воспользоваться каким-то проксирующим ПО (например,
haproxy или mysqlproxy), которое бы отслеживало доступность серверов.
Неактивен
Эммм, я Ваш ответ тоже не очень понял)) Попробую описать иначе.
На мастер сервере стоит веб-сервер, который юзает мастер базу. На слейв мы просто скидываем данные и не используем их.
Отключаем мастер сервер полностью (вылили на него литр воды
), поднимаем на слейве веб-сервер, настраиваем его на работу с БД этого сервера и восстанавливаем работу веб-сервисов.
Надо ли что-то донастроить на слейве? Придётся ли его сделать мастером/отключить репликацию или он без мастера тоже сможет работать? Как я писал выше, мастера выключили полностью, его просто не существует и слейв остался совсем один
И в будущем, скорее всего, ему придётся стать мастером, а к нему подключить слейв, для подобных ситуаций.
Неактивен

Если Вы хотите вручную переключать, то так, как Вы описали, — можно, конечно, реплика —
это точно такой же сервер. Обычно, однако, стремятся к тому, чтобы переключала автоматика,
ибо литр воды проливает уборщица в три ночи, как правило.
Неактивен
А для автоматики что у нас может использоваться? Указанное выше ПО?
Неактивен

С этим всё сложнее. Но можно пробовать начинать с него, да.
Неактивен
Тогда ещё такой вопрос. Сейчас на единственном СУБД данных примерно на 30Гб в таблицах MyISAM. Если настроить его как мастер и подключить к нему слейв, данные начнут сливаться сразу же и все скопом, что приведёт к блокировкам всех данных или есть какая-то возможность отложенной репликации?
Неактивен
И ещё один интересный вопросец... Бывало как-то по "затурканности" нажималась не та кнопка, что планировалось, в итоге табличка очищалась под ноль
Т.к. это ошибочное действие, его не надо реплицировать на слейв, а более того, хорошо бы данные со слейва вернуть. Есть такие возможности и ограничения на реплицируемые действия?
Неактивен

Репликация передает только изменения данных. За перенос скопом отвечает сам админ ![]()
Нет, таких ограничений нет. Для того, чтобы избавиться от таких ошибок, обычно
используют бэкапы.
Неактивен
paulus написал:
Репликация передает только изменения данных. За перенос скопом отвечает сам админ
Т.е. старые данные никак не попадут на слейв с помощью репликаций? Но ведь нельзя быть уверенным в актуальности данных при заливе бекапа. Например, мы заливаем дамп, данные которого на данный момент апдейтятся на мастере или что ещё интереснее - добавляются новые. Апдейты приходят на слейв, но т.к. дамп ещё не развёрнут, то запросы ничего не изменят. Или есть какая-то возможность притормозить репликацию на какое-то время, за которое можно развернуть дамп и потом выполнить все запросы в очереди репликации? В таком случае, как подскажете практически развернуть дамп, который создаётся в 3 часа ночи? ![]()
Я ж писал, вопросы нубские))
Неактивен

mysqldump --master-data --lock-all-tables в случае с MyISAM, или заменить на
--single-transaction последний параметр в случае с InnoDB. Восстановить на
реплике, начать репликацию с положения, указанного в полученном файлике ![]()
Неактивен
Ага, пока понятно, спасибо ![]()
Неактивен