Hello! On Thursday 17 December 2009 15:37:41 Max Kosmach wrote: > Т.е. опять завершенная транзакция вполне себе в файле и ее откатывать не > надо, только данные переместить.
Только _не в том_ файле. Завершенная транзакция после сброса буферов обязана быть в файле журнала, где ведется diff изменений. А вот когда эта транзакция будет перемещена в файлы таблиц, база решает сама, да еще и sync им делаети в разное время. Так что приходится брать устаревший дамп и последовательно "накатывать" на него все изменения, зафиксированные в журнале. > Вот эту часть я как-то до конца не осознал. > Мы берем и делаем в момент времени X снапшот файловой системы. > В нем будут все данные, которые БД записала на диск. (fsync) > Ничего явно обнулять и тд не надо. Вы забываете о том, что каждый файл sync-ается по отдельности. И не существует момента времени, когда можно сделать снапшот базы в консистентном состоянии. > Другое дело, что если допустим какой-то простой, то таки можно > средствами БД заблокировать доступ и сбросить все данные на диск и вот > после этого сделать снапшот и разблокировать доступ. > Тогда после запуска со снапшота и восстанавливать ничего не придется. _Все_ данные сбросить на диск нельзя при включенном сервере СУБД. Можно сбросить только промежуточные буферы в промежуточные файлы (см. выше про журнал), а сами файлы данных одновременно не бывают в консистентном состоянии. > Можно описать методику измерений, настройки и привести таки цифры? > Потому как я наличие LVM вообще не замечал особо при тестах (ну т.е. > разница пределах 5% была), хотя специально БД не тестировал, да и нет у > меня промышленных БД достаточного объема с большой нагрузкой. Не получится, т.к. сейчас не использую. На тестах у меня тоже проблем не было, на той же машине, а вот с многопользовательской БД все проседало. Из симптомов - десятки процессов pdflush и зашкаливающий LA. > Ну или ссылки на места, где "не рекомендуют"? Документация постгреса, точное место не назову. Документация оракла, где и вовсе рекомендуют использовать raw devices. Множество блогов разработчиков. Best regards, Alexey Pechnikov. http://pechnikov.tel/
