The Russian wiki is no longer maintained and is in read-only mode. Information contained within may be inaccurate or outdated. Please go to the English wiki for more up to date information.

Автоматический перевод с английского: Русская вики больше не поддерживается и находится в режиме только для чтения. Информация, содержащаяся в ней, может быть неточной или устаревшей. Пожалуйста, перейдите на английскую вики для получения более актуальной информации.

Berkley DB

Материал из Bitcoin Wiki
Перейти к навигации Перейти к поиску
Версия для печати больше не поддерживается и может содержать ошибки обработки. Обновите закладки браузера и используйте вместо этого функцию печати браузера по умолчанию.

berkeleydb это, вообще-то, один из самых производительных движков для DB из существующих (steam его использует, к примеру.. да и даже в том же mysql раньше была возможность хранения таблиц в berkeleydb, пока оракл не начал давить патентами в свое время). И поддерживает в том числе и репликацию.

Скачиваете с сайта оракла пакет libdb соответствующей версии, в нем куча утилит для работы с БД.

  • db_dump/db_load - снятие текстового дампа с базы/восстановление базы из дампа (дампы намного больше по размеру, чем сама база)
  • db_hotbackup - копирование базы данных "как есть"
  • db_verify/db_recover - проверка на повреждения/исправление поврежденной БД
  • db_deadlock - демон, который можно использовать для разрешения возможных ситуаций со взаимными блокировками
  • db_checkpoint - демон, позволяющий создавать контрольные точки с настраиваемыми интервалами между ними
  • db_stat - отображает статистику по БД
  • db_sql - утилита, позволяющая сгенерировать скелет конструкций на языке С/С++ для работы с Berkeley DB, на основании заданной на языке SQL схемы
  • db_archive - создает список файлов журналов, которые надо бэкапить на случай полного разрушения БД
  • db_upgrade - обновление формата БД до текущей версии

Для master-master и вообще какой бы то ни было репликации нужно чтобы использующее БД приложение было написано соответствующим образом, текущая реализация работы с БД не позволяет использовать подобный функционал т.к. в биткоине база используется не более как свалка ключей и значений. В этом плане, в общем, еще есть куда расти и очень далеко (как с master-master на berkeley db не в курсе, оракл вроде много на эту тему говорил... но master-slave достаточен в большинстве случаев и не является чем-то необычным для berkeley db).

Вообще, в bitcoin предусмотрена возможность делать flush для валлета (эта процедура вызывается периодически сама, ну и при некоторых действиях, таких как скачивание блока, содержащего принадлежащую клиенту транзакцию), что существенно снизит риски при копировании "на горячую" (практически до нуля), но почему-то в RPC calls эта функция не реализована.

Для того, чтобы безболезненно можно было работать с уже заблокированной базой bitcoin необходимо в RPC реализовать не flush, а flush-block и unblock-reread, при которых база будет переводиться в состояние, доступное для работы другим приложениям (и открывать естественно в режиме shared write), а при попытках записать что-либо между этими вызовами - блокировать работу клиента.

Что то мне говорит, если немного подсуетиться, безо всяких изобретений новых вызовов одновременная работа с базой возможна и так, всего то сменить режим открытия базы и реализовать коллбаки на модификацию базы в критических местах.

резервное копирование кошелька необходимо делать после каждой операции, а если он гигабайтового размера, то это несколько затруднительно