mdbx: minor refine README.md

Change-Id: I7e2253fc83240b7653eac1690493dcd3ee5ebe97
This commit is contained in:
Leo Yuriev 2017-01-09 02:04:31 +03:00
parent 81861084fc
commit c96cc9c567

View File

@ -22,8 +22,7 @@ Database](https://symas.com/products/lightning-memory-mapped-database/)
Изначально модификация производилась в составе исходного кода проекта Изначально модификация производилась в составе исходного кода проекта
[ReOpenLDAP](https://github.com/ReOpen/ReOpenLDAP). Примерно за год работы [ReOpenLDAP](https://github.com/ReOpen/ReOpenLDAP). Примерно за год работы
внесенные изменения приобрели самостоятельную ценность вне контекста внесенные изменения приобрели самостоятельную ценность.
ReOpenLDAP.
Осенью 2015 доработанный движок был выделен в отдельный проект, который был Осенью 2015 доработанный движок был выделен в отдельный проект, который был
[представлен на конференции Highload++ [представлен на конференции Highload++
@ -192,19 +191,28 @@ MDBX.
что имеет ряд преимуществ. Так например, при крахе приложения, ядро ОС что имеет ряд преимуществ. Так например, при крахе приложения, ядро ОС
сохранит все изменения. сохранит все изменения.
Однако, при аварийном отключении питания или сбоя в ядре ОС, на диске будет Однако, при аварийном отключении питания или сбое в ядре ОС, на диске будет
сохранена только часть измененных страниц БД. При этом с большой вероятностью сохранена только часть измененных страниц БД. При этом с большой вероятностью
может оказаться так, что будут сохранены мета-страницы с указателям на станицы может оказаться так, что будут сохранены мета-страницы со ссылками на страницы
с новыми версиями данных, но не сами данные. В этом случае БД будет с новыми версиями данных, но не сами новые данные. В этом случае БД будет
безвозвратна разрушена, даже если до аварии производилась полная синхронизация безвозвратна разрушена, даже если до аварии производилась полная синхронизация
данных (посредством `mdb_env_sync()`). данных (посредством `mdb_env_sync()`).
В MDBX эта проблема решена, на текущий момент как минимум частично. При В MDBX эта проблема решена путем полной переработки пути записи данных:
завершении транзакций MDBX помечает точки фиксации как сильные (strong), либо
как слабые (weak). Так в режиме `WRITEMAP` завершаемые транзакции помечаются * В режиме `WRITEMAP` MDBX не обновляет мета-страницы непосредственно,
как слабые, а при явной синхронизации данных как сильные. При открытии БД а поддерживает их теневые копии с переносом изменений после фиксации
выполняется автоматический откат к последней сильной фиксации. Этим данных.
обеспечивается гарантия сохранности БД.
* При завершении транзакций, в зависимости от состояния
синхронности данных между диском и оперативной память, MDBX помечает
точки фиксации либо как сильные (strong), либо как слабые (weak). Так
например, в режиме `WRITEMAP` завершаемые транзакции помечаются как
слабые, а при явной синхронизации данных как сильные.
* При открытии БД
выполняется автоматический откат к последней сильной фиксации. Этим
обеспечивается гарантия сохранности БД.
К сожалению, такая гарантия надежности не дается бесплатно. Для сохранности К сожалению, такая гарантия надежности не дается бесплатно. Для сохранности
данных, страницы формирующие крайний снимок с сильной фиксацией, не должны данных, страницы формирующие крайний снимок с сильной фиксацией, не должны