|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Есть задача иметь 2 сервера на разных хост площадках, чтобы при отключении основного, второй оставался доступен и при этом не останавливалась работа сервиса.
Отсюда у меня вопрос, если настроить репликацию и мастер сервер просто выключить из сети, будет ли слейв работать с клиентами самостоятельно? Т.е. изначально все запросы отправляются на мастер, а когда он недоступен - надо отправлять на слейв. Скушает ли он их? Я предполагаю, что не скушает и его надо будет перенастроить как самостоятельный серв. Правильно ли я мыслю?
Неактивен
Честно говоря, не понял, в чем вопрос. Если Вас устроит работоспособность сервиса
в режиме «только на чтение», то проблемы никакой нет — Вам нужно настроить обыч-
ную репликацию (и запилить права доступа на реплике, чтобы туда нельзя было пи-
сать), а потом научить ПО ходить в мастер (а в случае неуспеха — в реплику). Если
ПО учить тяжело — можно воспользоваться каким-то проксирующим ПО (например,
haproxy или mysqlproxy), которое бы отслеживало доступность серверов.
Неактивен
Эммм, я Ваш ответ тоже не очень понял)) Попробую описать иначе.
На мастер сервере стоит веб-сервер, который юзает мастер базу. На слейв мы просто скидываем данные и не используем их.
Отключаем мастер сервер полностью (вылили на него литр воды 
), поднимаем на слейве веб-сервер, настраиваем его на работу с БД этого сервера и восстанавливаем работу веб-сервисов.
Надо ли что-то донастроить на слейве? Придётся ли его сделать мастером/отключить репликацию или он без мастера тоже сможет работать? Как я писал выше, мастера выключили полностью, его просто не существует и слейв остался совсем один И в будущем, скорее всего, ему придётся стать мастером, а к нему подключить слейв, для подобных ситуаций.
Неактивен
Если Вы хотите вручную переключать, то так, как Вы описали, — можно, конечно, реплика —
это точно такой же сервер. Обычно, однако, стремятся к тому, чтобы переключала автоматика,
ибо литр воды проливает уборщица в три ночи, как правило.
Неактивен
А для автоматики что у нас может использоваться? Указанное выше ПО?
Неактивен
С этим всё сложнее. Но можно пробовать начинать с него, да.
Неактивен
Тогда ещё такой вопрос. Сейчас на единственном СУБД данных примерно на 30Гб в таблицах MyISAM. Если настроить его как мастер и подключить к нему слейв, данные начнут сливаться сразу же и все скопом, что приведёт к блокировкам всех данных или есть какая-то возможность отложенной репликации?
Неактивен
И ещё один интересный вопросец... Бывало как-то по "затурканности" нажималась не та кнопка, что планировалось, в итоге табличка очищалась под ноль Т.к. это ошибочное действие, его не надо реплицировать на слейв, а более того, хорошо бы данные со слейва вернуть. Есть такие возможности и ограничения на реплицируемые действия?
Неактивен
Репликация передает только изменения данных. За перенос скопом отвечает сам админ
Нет, таких ограничений нет. Для того, чтобы избавиться от таких ошибок, обычно
используют бэкапы.
Неактивен
paulus написал:
Репликация передает только изменения данных. За перенос скопом отвечает сам админ
Т.е. старые данные никак не попадут на слейв с помощью репликаций? Но ведь нельзя быть уверенным в актуальности данных при заливе бекапа. Например, мы заливаем дамп, данные которого на данный момент апдейтятся на мастере или что ещё интереснее - добавляются новые. Апдейты приходят на слейв, но т.к. дамп ещё не развёрнут, то запросы ничего не изменят. Или есть какая-то возможность притормозить репликацию на какое-то время, за которое можно развернуть дамп и потом выполнить все запросы в очереди репликации? В таком случае, как подскажете практически развернуть дамп, который создаётся в 3 часа ночи?
Я ж писал, вопросы нубские))
Неактивен
mysqldump --master-data --lock-all-tables в случае с MyISAM, или заменить на
--single-transaction последний параметр в случае с InnoDB. Восстановить на
реплике, начать репликацию с положения, указанного в полученном файлике
Неактивен
Ага, пока понятно, спасибо
Неактивен
