Re: Master-slave репликация для SQLite - теоретический вопрос.
On 17.12.2009 15:19, Alexey Pechnikov wrote:
> Hello!
>
> On Thursday 17 December 2009 14:55:28 Max Kosmach wrote:
>> On 17.12.2009 13:15, Alexey Pechnikov wrote:
>>> Как уже ответил Артем, в базе выполняется множество служебных процессов,
>>> например, сбор и обработка статистики. Кроме того, происходит
>>> инкрементальная сборка мусора, сброс журналов на диск... Для
>>> принудительного сохранения журналов на диск существуют способы, но
>>> при этом для их дальнейшего применения вам все равно понадобится дамп базы
>>> определенной давности.
>>
>> Зачем, если у нас будет срез файлов БД на конкретный момент времени?
>> Я так понимаю что из этого состояния любая вменяемая БД должна подняться
>> в полностью рабочее состояние откатив незавершенные транзакции, так?
>
> Откатив как незавершенные, так и завершенные, но не сохраненные транзакции.
>
> Клиент-серверные СУБД по коммите транзакции отнюдь не сохраняют данные
> сразу, а буферизуют их, чтобы записывать их большими блоками (для повышения
> производительности). Причем сначала пишут в файл журнала, а потом уже
> в сами файлы таблиц.
Угу
Ключевое слово -в файл.
Т.е. опять завершенная транзакция вполне себе в файле и ее откатывать не
надо, только данные переместить.
> Если явно сбросить буфер журнала, то журнал мы получим,
> но файлы таблицы в это время модифицируются и при их копировании скорее всего
> будут повреждены. Потому и нужен корректный дамп, к которому мы добавим
> изменения, выполненные после снятия этого дампа.
Вот эту часть я как-то до конца не осознал.
Мы берем и делаем в момент времени X снапшот файловой системы.
В нем будут все данные, которые БД записала на диск. (fsync)
Ничего явно обнулять и тд не надо.
Другое дело, что если допустим какой-то простой, то таки можно
средствами БД заблокировать доступ и сбросить все данные на диск и вот
после этого сделать снапшот и разблокировать доступ.
Тогда после запуска со снапшота и восстанавливать ничего не придется.
>> Заче для этого nilfs/etc, если есть давно работающий LVM?
>
> Использовать LVM с базами данных, мягко говоря, не рекомендуют. Проверил на
> своей шкуре - зеркало на mdadm плюс lvm "просадили" производительность
> постгреса вдесятеро. В итоге чуть нагрузка увеличилась и LA>30, после чего за
> полминуты LA>300 и полный коллапс. Без mdadm и lvm на том же оборудовании
> редко когда LA>2 поднимается, и то максимум до 4-х (и это не говоря о том,
> что за прошедшее время и нагрузка примерно удвоилась).
> Так что "работающим" lvm назвать можно только с большой натяжкой - где-то
> как-то работает, да, но не в области использования БД.
Можно описать методику измерений, настройки и привести таки цифры?
Потому как я наличие LVM вообще не замечал особо при тестах (ну т.е.
разница пределах 5% была), хотя специально БД не тестировал, да и нет у
меня промышленных БД достаточного объема с большой нагрузкой.
Ну или ссылки на места, где "не рекомендуют"?
> Кроме того, LVM умеет делать снапшот, который можно замонтировать и
> использовать параллельно с работой основной версии ФС? Достаточно read-only.
>
Конечно умеет, затем и нужен.
Иногда, правда, (например с xfs) нужно специальным документированным
образом это объяснить команде mount.
--
With MBR
Max
CCSA/CCSE
Reply to: