Re: Master-slave репликация для SQLite - теоретический вопрос.
Hello!
On Wednesday 16 December 2009 15:31:40 Nicholas wrote:
> Всегда было интересно понять, можно ли использвать такие средства как
> DRBD для "репликации" баз данных?
>
> Или это в принципе не возможно ?
>
В общем и целом - возможно. Но на практике все интереснее. Если говорить
о клиент-серверных СУБД, то у них файлы фактически никогда не бывают в
согласованном состоянии - для оптимизации записи используются несколько
уровней буферов, так что для получения целостных данных нужно еще и
содержимое оперативной памяти. Соответственно, DRBD можно использовать
для сервера "горячего резерва", но при падении основного сервера и запуске
резервного последние транзакции будут потеряны. Собственно, СУБД этого
класса бывает удобно разделить на две группы - те, которые при старте с
поврежденными файлами самовосстанавливаются (как пример, постгрес) и
которые уже не могут восстановить базу самостоятельно и, быть может,
даже с помощью админа (мускуль). Бывают и исключения, конечно. Но чудес
не бывает и количество транзакций в секунду ограничено - нужно 2 оборота
диска на гарантированную фиксацию, значит, на диске 7200 rpm пределом
будет 60 транзакций записи в секунду. Учтем накладные расходы, останется
в лучшем случае 10 транзакций в секунду. Размеры буферов зависят от
настроек, равно как и частота их синхронизации, но если у нас 100 пишущих
транзакций в секунду, то любой клиент-сервер при "падении" потеряет не
менее 10-ти транзакций, а скорее всего, как раз порядка сотни за последнюю
секунду, а на нагруженной системе и того больше. Эти данные уже не
вернуть, так что ничего не мешает запустить систему на другом хосте, куда
синхронизируется DRBD. Задержка синхронизации DRBD в локалке погоды
в такой ситуации уже не делает.
Что касается файловых СУБД, то у них в режиме полной синхронизации
записи все завершенные транзакции - на диске, так что данные не теряются.
Здесь идеально бы подошла логирующая ФС, т.к. по ней можно было бы
вернуться на момент времени, предшествующий незавершенной транзакции
и спокойно продолжить работу. Понятно, что незавершенная транзация не
является потерей данных, т.к. подтверждение о завершении операции не
было получено и отображено пользователю/другому приложению. С
имеющимися файловыми системами гарантий нет, хотя и проблем быть не
должно. А вот если полная синхронизация отключена, то база при крэше
будет почти наверняка убита, такова плата за увеличение быстродействия.
Ситуацию, когда сама файловая система оказывается нерабочей, вряд ли
переживет любая база, так что эту ситуацию не рассматриваем.
Представленное в топике решение направлено на получение гарантированно
работоспособной реплики основной базы, более того, при неработоспособности
основной БД синхронизация не может быть выполнена. Но есть нюанс - т.к.
эскулайт не позволяет одновременно читать и модифицировать БД,
синхронизация должна выполняться очень быстро, примерно 1 Гб данных в
секунду (на моих базах, чтобы задержка записи была не более 3-4х секунд).
Выход один - не проверять чексумму всех данных, а только новых. Эту задачу
позволяет решить расширение history, на основе которого сейчас я делаю
timeback машину для БД и инкрементальный репликатор. А полная репликация
будет запускаться в периоды бездействия системы (ночью), позволяя в бэкапах
сохранять дельты изменений в виде валидных БД, которые легко можно
анализировать вручную или автоматически. Размер дневной дельты для
полуторагиговой базы около 4 Мб, а сигнатуры примерно 20 Мб, имхо
прекрасный результат, так что бинарные дельты и сигнатуры просто не
требуются. Есть и другие возможности применения названных расширений.
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Reply to: