Berkley DB

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), а при попытках записать что-либо между этими вызовами - блокировать работу клиента.

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

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