Исходные данные: имеется сервер БД, на котором происходит изменение данных (вставка, удаление, обновление) + выборка (основной сервер).
Также имеется второй сервер, аналогичный первому (резервный). Сервера находятся в разных дата-центрах. На серверах развёрнута СУБД MySQL 5.1.33, всё крутится под управлением ОС FreeBSD 8.0, 95% таблиц использует движок InnoDB.
Конфигурация серверов: Core 2 Duo Quad, 8GB RAM, HDD 500GB, 100Mbit internet;

Задача: обеспечить плавный переход на резервный сервер в случае, если основной сервер по какой-то причине ложится. Под плавным переходом подразумевается

полное переключение на работу с БД на резервном сервере в течение 5-10 минут. Естественно, мусолится вариант с репликацией (master - slave схема). Основной сервер - Master, резервный - Slave. Соотв. они меняются местами, когда основной падает, т.е. резервный становится основным. Когда упавший сервер оживает, он становится резервным (на него переносится БД с нового master сервера, и он в свою очередь становится slave сервером).

Схема не очень нравится, т.к. надо париться с переносом БД, когда упавший сервер оживает (а базы весят много, больше 10Гб). Если базы не переносить, а просто настроить снова репликацию в обратную сторону, то может быть проблема в случае, если перед падением основного сервера на нём в БД что-то писалось, и он не успел это отреплицировать на slave сервер.

Отсюда вопрос: какие схемы используете вы в своих проектах и пользуетесь ли вы схемой master - master (про подводные камни этого решения знаю немного)?

Что, никто такими вещами не занимается на форуме или специалисты тут не водятся? :)

OrtogonGeniussЧто, никто такими вещами не занимается на форуме или специалисты тут не водятся? :)
Сдается мне, вы просто немного не в том разделе тему забили.

Да вроде бы тема соответствует разделу. Ваши предложения по переносу?

Условия исходной задачи поменять нельзя: используется именно СУБД MySQL. Oracle находится совсем в другой весовой категории, там наверняка есть общепринятые механизмы решения такого рода задач.

SERG1257,

А сколько серверов принимает участие в схеме, три?

pilot911,

Спасибо, открою тему параллельно и там.

Kew,

> ...а это неприемлемое время на перекачку между датацентрами?

Ну как, сервера могут быть территориально разбросаны, скажем один в США, другой в Европе. Хотя, конечно, с учётом того, что сервера падают далеко не каждый день - это в принципе приемлемое решение, тем не менее может есть лучшие решения.

>можно сделать четырехнодное кольцо с двумя серверами в одном ДЦ и двумя в другом.
>Оно, кстати, и в мультимастер может работать...

А можно поподробнее? Я так понимаю, два сервера выступают в роли одного и находятся они в одном ДЦ?

SERG1257GeniussА сколько серверов принимает участие в схеме, три?
Серверов два, на каждом по две базы. Одна открыта, другая нет.

Схема в принципе реализуемая, наверное. Из плюсов стоит отметить возможность снятия бэкапов на основном сервере со скрытой СУБД. Впрочем, это можно делать и на втором (slave) сервере.

Надо теперь изучить вопрос с накатыванием логов в MySQL. Правда, проблема тут возникнет в случае, если лог накатили на копию (локальную скрытую БД), но не успели передать на slave сервер, т.к. эта операция по сути неатомарная и выполняется не в транзакции. Тогда в случае поднятия старого master сервера придётся попариться с его синхронизацией с новым master сервером. Если же падение произошло после того, как накатили лог на копию и передали на slave сервер, достаточно будет просто скопировать копию на основную базу на старом master сервере и запустить репликацию в обратную сторону.


KewВ мануале по мускулю на его официальном сайте описана схема кольцевой репликации.

Если
1. Репликация устроена так: Сервер1->Сервер2->Сервер3->Сервер4->(обратно Сервер1)
2. Сервер1, Сервер2 сидят в одном датацентре, Сервер3, Сервер4 -- в другом
3. Изменяются данные только в Сервер2 или паре Сервер2 и Сервер 4
то
1. Восстановление павшего Сервер 2 возможно сразу после окончания репликации отправленного с него лога на Сервер1 (это время можно довести до единиц секунд)
2. Восстановление производится из рядом расположенного Сервер1, т.е., очень быстро.
3. Отправленные с Сервер2 логи можно архивировать/чистить сразу после появления их в Сервер1, т.е. нужно обеспечить надежное хранение, в большинстве случаев, жалких единиц мегабайт данных.
но
1. Компов в два раза больше
:)
Для случая падения Сервер1 процедура восстановления даже проще.

Тут вопрос в рациональности такой схемы. Дело в том, что если у нас два сервера в одном ДЦ - это уже залог неплохой стабильности, т.к. сервера в нормальном западном ДЦ падают не так уж и часто, а два сразу - так тем более. Единственный возможный вариант - отваливание всего ДЦ, но опять же - такое тоже крайняя редкость.


По теме репликации, в том числе кольцевой, нарыл немного инфы, кому интересно - сюда:
http://onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html
http://www.scribd.com/doc/2569408/MySQL-Replication-Tutorial
http://forums.mysql.com/read.php?26,110341,110341

Между прочим, товарищ предложил интересный вариант.
Имеется два сервера в одном ДЦ, между ними гигабитный коннекшн, на каждом установлена СУБД MySQL. Один сервер основной (на нём работает MySQL), другой резервный (на нём MySQL развёрнута, но выключена).

ФС обоих серверов построена, скажем, на базе вот этого: http://en.wikipedia.org/wiki/Chiron_FS. То есть у них общая ФС. Обоим доступен некоторый раздел, на котором находятся все базы, т.к. ФС общая. Ну и дальше понятно: на основном идут все операции (чтение / запись), резервный ждёт своего часа. Когда падает основной сервер, мгновенно включается MySQL на резервном и процесс продолжается дальше :) т.е. репликация данных, если так можно выразиться, происходит уже на уровне самой ФС, а не приложения.

Внешне выглядит очень заманчиво. Критика приветствуется)

SERG1257Для параноиков можно три базы на сервер (на сервера для суперпараноиков) чтобы обеспечить накат изменений как одну супертранзакцию (если она обломилась по любой причине, у нас все равно есть консистентная копия, а с бакапом возится каждый раз хлопотно). Еще лучше если третья база будет отставать от первых двух на один-два наката ()
Данная схема была разработана для наката логов для Oracle Standard Edition. Насколько это применимо к МySQL решать вам, я МySQL не знаю совсем.

Это совсем уже для параноиков)

Update: по поводу описанной схемы с общей ФС.
Описано тут: http://www.scribd.com/doc/2569408/MySQL-Replication-Tutorial (слайд №57).