Re: Master-slave репликация для SQLite - теоретический вопрос.
On 17.12.2009 16:38, Alexey Pechnikov wrote:
> Hello!
>
> On Thursday 17 December 2009 15:37:41 Max Kosmach wrote:
>> Т.е. опять завершенная транзакция вполне себе в файле и ее откатывать не
>> надо, только данные переместить.
>
> Только _не в том_ файле. Завершенная транзакция после сброса буферов обязана быть
> в файле журнала, где ведется diff изменений. А вот когда эта транзакция будет
> перемещена в файлы таблиц, база решает сама, да еще и sync им делаети в разное
> время. Так что приходится брать устаревший дамп и последовательно "накатывать"
> на него все изменения, зафиксированные в журнале.
Это все так.
Но мы-то делаем снапшот не файла, а всей ФС. Т.е. и файлов табличных
пространств и журнала. причем в один и тот же момент времени.
И соотвественно БД ничего ен мешает потом точно также перенести данные
из журнала в файлы табличных пространств.
>
>> Вот эту часть я как-то до конца не осознал.
>> Мы берем и делаем в момент времени X снапшот файловой системы.
>> В нем будут все данные, которые БД записала на диск. (fsync)
>> Ничего явно обнулять и тд не надо.
>
> Вы забываете о том, что каждый файл sync-ается по отдельности. И не
> существует момента времени, когда можно сделать снапшот базы в
> консистентном состоянии.
Хм, мне казалось, что пока СУБД не получила инфорации о том, что данные
успешно перенесены из журнала в файлы данных - она в журнале эту запись
не пометит как обработанную. И, соотвественно, нам не важно, что sync
происходит в разные моменты времени.
И потом - я вроде уже писал о том, что для того, чтобы гарантированно
сделать бакап в консистентном состоянии помощь от СУБД нужна
(pg_start_backup/pg_stop_backup и тд тп).
Но эта помощь не является необходимой для того, чтобы сделать бакап,
который с точки зрения СУБД будет вполне валидным, пусть и не на время
создания бакапа, а чуть более раннее. Просто СУБД после запуска придется
откатить незавершенные транзакции, перенести записи из журнала в файлы и тд.
Но это все вполне штатные операции.
В рассуждениях выше есть, правда, один изъян - все это работает если
журнал и файлы данных на одной ФС и снапшот будет сделан строго
одновременно.
>> Другое дело, что если допустим какой-то простой, то таки можно
>> средствами БД заблокировать доступ и сбросить все данные на диск и вот
>> после этого сделать снапшот и разблокировать доступ.
>> Тогда после запуска со снапшота и восстанавливать ничего не придется.
>
> _Все_ данные сбросить на диск нельзя при включенном сервере СУБД.
> Можно сбросить только промежуточные буферы в промежуточные файлы
> (см. выше про журнал), а сами файлы данных одновременно не бывают в
> консистентном состоянии.
Ну, и как я выше написал в меру своего понимания - это вообще не
является необходимым,
если отсутствие части данных(незавершенные транзакции) в БД - нормально.
Т.е. если я правильно понимаю, то БД гарантирует, что после успешного
окончания транзакции все данные лежат на диске(вожможно что в журнале,
этого достаточно).
>> Можно описать методику измерений, настройки и привести таки цифры?
>> Потому как я наличие LVM вообще не замечал особо при тестах (ну т.е.
>> разница пределах 5% была), хотя специально БД не тестировал, да и нет у
>> меня промышленных БД достаточного объема с большой нагрузкой.
>
> Не получится, т.к. сейчас не использую. На тестах у меня тоже проблем не было,
> на той же машине, а вот с многопользовательской БД все проседало. Из
> симптомов - десятки процессов pdflush и зашкаливающий LA.
Не могло получиться? что разделы для md/lvm были например не выровнены
по границе chunk'ов?
Надо будет найти кого-нибудь, кто использует активно постгрес и
поспрашивать.
>
>> Ну или ссылки на места, где "не рекомендуют"?
>
> Документация постгреса, точное место не назову.
Пролистал еще раз - так сразу не нашел, поищу еще.
> Документация оракла, где
> и вовсе рекомендуют использовать raw devices. Множество блогов разработчиков.
Ну не так уж и активно они raw devices пропагандируют в последнее время.
В блогах - да, есть записи, но я что-то не встречал ссылок на 10-кратное
падение производительности. Обычно речь идет максимум о десятках процентов.
Впрочем я не Oracle DBA, врать не буду.
--
With MBR
Max
CCSA/CCSE
Reply to: