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 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
