Backing up and Restoring Berkeley DB, Java Edition Applications （备份和还原Berkeley DB,Java Edition 应用程序）
从根本上说，您通过将JE日志文件复制到安全存储位置来备份数据库。要从备份还原数据库，请将这些文件复制到磁盘上的相应目录，然后重新启动JE应用程序。
请注意，如果您使用子目录存储JE日志文件，则备份和还原过程必须维护每个日志文件与JE最初放置它的子目录之间的关系。也就是说，如果JE将日志文件号17放在名为data003的子目录中，那么当您执行恢复日志时，文件号17必须放在子目录data003中。
除了这些简单的活动之外，您可能还需要考虑一些不同的备份策略。本章将介绍这些主题。
在继续之前，在查看“Berkeley DB入门”Java Edition指南中有关日志文件和后台线程的信息之前。这些主题包含以下有关备份和还原的讨论的基本信息。
Normal Recovery 普通还原
请记住，内部JE数据库是在BTree中组织的，并且为了操作JE，需要完整的BTree才能使用它。
创建，修改或删除数据库记录时，修改将在BTree的叶节点中表示。除了叶节点更改之外，数据库记录修改还可以导致对其他BTree节点和结构的更改。
现在，如果您的写入受事务保护，则每次提交事务时，由该事务修改的叶节点（以及仅叶子节点）将写入磁盘上的JE日志文件。此外，请记住写入的持久性（无论是执行刷新还是fsync）取决于所请求的提交类型。有关详细信息，请参阅非持久性事务。
然后，正常恢复是从叶节点中可用的信息重建整个BTree的过程。您无需执行任何特殊操作即可运行正常恢复;每次打开JE环境时都会发生这种情况。
您可以通过捕获EnvironmentFailureException来了解是否必须运行正常恢复。此异常表示发生了影响整个环境的故障。看到此异常后，您应该运行Environment.isValid（）。如果返回true，则可以继续操作而无需任何进一步操作。但是，如果它返回false，则必须关闭并重新打开所有Environment句柄，以便可以运行正常恢复。
Checkpoints 检查点
如果随着时间的推移，所有写入磁盘的都是BTree叶节点，那么运行正常恢复会变得昂贵。因此，为了限制正常恢复所需的时间，JE运行检查点。检查点将所有内部BTree节点和结构写入日志文件，作为写入操作的一部分进行修改。这意味着您的日志文件包含一个完整的BTree，直到检查点运行的那一刻。结果是，正常恢复仅需要重新创建自上次检查点开始以来已被修改的BTree部分。
检查点通常会向磁盘写入比事务提交更多的信息，因此从磁盘I / O角度来看它们更昂贵。因此，您需要考虑将检查点作为性能调优活动的一部分运行的频率。执行此操作时，请平衡检查点的成本与应用程序重新启动所需的时间，因为运行正常恢复的成本。
检查点通常由检查点背景线程执行，该线程始终在运行。与所有后台线程一样，它使用je.properties文件进行管理。目前，您可能想要管理的唯一checkpointer属性是je.checkpointer.bytesInterval。此属性标识在运行检查点之前JE的日志文件可以增长多少。其值以字节为单位指定。减小此值会导致检查点线程更频繁地运行检查点。这将缩短运行恢复所需的时间，但也会增加JE所需的系统资源（特别是I / O）。
请注意，当环境正常关闭时，也始终执行检查点。因此，正常恢复只有在应用程序崩溃或以其他方式异常结束而不调用Environment.close（）时才能执行。
Performing Backups 执行备份
本节介绍如何备份JE数据库，以便可以进行灾难性恢复。
要备份数据库，您可以进行热备份或脱机备份。 在数据库写入操作正在进行时执行热备份。
不要将脱机备份和热备份与完全备份和增量备份的概念混淆。 脱机备份和热备份都是完全备份 - 您备份整个数据库。 它们之间的唯一区别是内存缓存中包含了多少内容。 另一方面，增量备份仅是自上次备份以来修改或创建的那些日志文件的备份。 大多数备份软件都能够为您执行完整备份和增量备份。
Performing a Hot Backup执行热备份
要执行JE数据库的热备份，请将所有日志文件（* .jdb文件）从环境目录复制到存档位置或备份媒体。 必须按字母顺序复制文件（数值有效）。 您不必为了执行此操作而停止任何数据库操作。
注意
如果使用子目录存储日志文件，则必须备份子目录，确保将日志文件保留在JE放置它们的子目录中。有关使用子目录存储日志文件的信息，请参阅“Berkeley DB入门”，Java版指南。
为了使这个过程更容易一些，您可能需要使用DbBackup帮助程序类。 有关详细信息，请参阅使用DbBackup Helper类。
Performing an Offline Backup 执行脱机备份
脱机备份可确保您在完成备份时完整地捕获了数据库，包括内存缓存的所有内容。为此，您必须确保没有正在进行的写入操作，并且所有数据库修改都已写入磁盘上的日志文件。要获取脱机备份：
停止编写数据库。
确保所有内存中的更改都已刷新到磁盘。如何执行此操作取决于您使用的事务类型：
如果您正在使用在提交时将所有脏数据写入磁盘的事务（这是默认行为），则只需确保提交或中止所有正在进行的事务。
如果您使用的是不在提交时同步写入的事务，则必须运行检查点。请记住，关闭环境会导致运行检查点，因此如果您的应用程序在进行备份之前完全关闭，则您已满足此要求。
有关更改事务同步行为的信息，请参阅非持久事务。有关运行检查点的信息，请参阅检查点。
如果您正在使用持久事务，则可以选择运行检查点。这样做可以缩短从此备份恢复数据库所需的时间。
将所有日志文件（* .jdb）从环境目录复制到存档位置或备份媒体。为了使这个过程更容易一些，您可能需要使用DbBackup帮助程序类。有关详细信息，请参阅下一节。
注意
如果使用子目录存储日志文件，则必须备份子目录，确保将日志文件保留在JE放置它们的子目录中。 有关使用子目录存储日志文件的信息，请参阅“Berkeley DB入门”，Java版指南。
您现在可以恢复正常的数据库操作。
Using the DbBackup Helper Class （使用DbBackup Helper 类）
为了简化备份操作，JE提供了DbBackup辅助类。 此类在开放环境中停止并重新启动JE后台活动。 它还允许应用程序创建备份，以支持将环境还原到特定时间点。
因为您不必为了进行备份而停止JE写入活动，所以通常需要在您确定备份完成之前检查两次日志文件。 这是因为JE可能会在您运行备份时创建新的日志文件。 对日志文件的第二次传递允许您确保没有创建新文件，因此您可以声明备份完成。
例如：
time files in activity
environment
t0 000000001.jdb Backup starts copying file 1
000000003.jdb
000000004.jdb
t1 000000001.jdb JE log cleaner migrates portion of file 3 to
000000004.jdb newly created file 5 and deletes file 3.
000000005.jdb Backup finishes file 1, starts copying file 4.
Backup MUST include file 5 for a consistent
backup!
t2 000000001.jdb Backup finishes copying file 4, starts and
000000004.jdb finishes file 5, has caught up. Backup ends.
000000005.jdbDbBackup通过定义必须为每个备份操作复制的文件集来解决此问题，并冻结对这些文件的所有更改。 应用程序可以复制该定义的文件集并完成操作，而无需检查是否正在创建新文件。 此外，无需在下次备份时检查最新文件的较新版本。
在上面的示例中，如果在t0使用DbBackup，则应用程序只需要复制文件1,3和4进行备份。 在后续备份中，应用程序可以在文件5处开始复制。不需要检查文件4的较新版本。
以下代码片段说明了此类的用法。 有关其他示例和有关增量备份的详细信息，请参阅DbBackup javadoc。
...
import com.sleepycat.je.util.DbBackup;
...
// Find the file number of the last file in the previous backup
// persistently, by either checking the backup archive, or saving
// state in a persistent file.
long lastFileCopiedInPrevBackup = ...
Environment env = new Environment(...);
DbBackup backupHelper = new DbBackup(env, lastFileCopiedInPrevBackup);
// Start backup, find out what needs to be copied.
// If multiple environment subdirectories are in use,
// the getLogFilesInBackupSet returns the log file
// name prefixed with the dataNNN/ directory in which
// it resides.
backupHelper.startBackup();
try {
String[] filesForBackup = backupHelper.getLogFilesInBackupSet();
// Copy the files to archival storage.
myApplicationCopyMethod(filesForBackup)
// Update our knowlege of the last file saved in the backup set,
// so we can copy less on the next backup
lastFileCopiedInPrevBackup = backupHelper.getLastFileInBackupSet();
myApplicationSaveLastFile(lastFileCopiedInBackupSet);
}
finally {
// Remember to exit backup mode, or all log files won't be cleaned
// and disk usage will bloat.
backupHelper.endBackup();
} Performing Catastrophic Recovery执行灾难性恢复
只要您的环境和/或数据库因介质故障（例如磁盘故障）而丢失或损坏，就必须进行灾难性恢复。如果正常恢复因任何原因失败，也需要进行灾难性恢复。
要执行灾难性恢复，您必须拥有数据库的完整备份。您将使用此备份来还原数据库。有关运行备份的信息，请参阅上一节。
执行灾难性恢复：
- 关闭你的应用程序
- 删除环境主目录（遇到灾难性故障的目录）的内容，如果有的话。
- 将最新的完整备份复制到环境主目录中。如果使用子目录存储日志文件，请确保将恢复的日志文件放回最初备份它们的子目录中。
- 如果您使用的是运行环境目录的增量备份的备份实用程序，请复制自上次完全备份以来生成的所有日志文件。确保按写入顺序还原所有日志文件。顺序很重要，因为可能在多个存档中显示相同的日志文件，并且您希望使用每个日志文件的最新版本运行恢复。
- 正常打开环境。将运行JE的正常恢复，这将使您的数据库相对于日志文件中找到的已更改数据处于一致状态。
您现在已完成恢复数据库。
Hot Failover 热故障转移
作为最终备份/恢复策略，您可以创建热故障转移。请注意，使用热故障转移要求应用程序能够在应用程序启动时指定其环境主目录。大多数应用程序开发人员允许使用命令行选项或配置或属性文件来标识环境主目录。如果您的应用程序将其环境主页硬编码到其中，则无法使用热故障转移。
您可以通过定期将数据库备份到磁盘上的备用位置来创建热故障转移。通常，此备用位置位于您通常保留数据库的单独物理驱动器上，但如果多个驱动器不可用，则至少应将热故障转移放在单独的磁盘分区上。
通过使应用程序使用故障转移位置重新打开其环境来进行故障转移。
请注意，不应将热故障切换用作替代将数据备份和存档到物理上远离计算环境的安全位置。即使您的数据分布在多个物理磁盘上，真正严重的灾难（火灾，恶意软件病毒，故障磁盘控制器等）仍然会导致您丢失数据。
要创建和维护热故障转移：
- 将所有日志文件（*
.jdb）从环境目录复制到要保留故障转移的位置。脱机或热备份可用于此目的，但通常最初通过对数据库进行脱机备份来创建热故障转移。这可确保您已捕获内存高速缓存的内容。
注意
如果使用子目录存储日志文件，则必须备份子目录，确保将日志文件保留在JE放置它们的子目录中。有关使用子目录存储日志文件的信息，请参阅“Berkeley
DB入门”，Java版指南。
2 . 定期将自上次复制之后更改或创建的任何日志文件复制到故障转移目录。大多数备份软件都能够为您执行此类增量备份。
请注意，增量副本的频率决定了由于灾难性故障而面临风险的数据量。例如，如果您每小时执行一次增量复制，那么最多的热故障转移比生产数据库落后一小时，因此您最多可能需要花费数小时的数据库更改。
3.从热故障切换目录中删除已删除或重命名为主目录中的.del文件的任何* .jdb文件。这对于一致性不是必需的，但有助于减少热故障转移所消耗的磁盘空间。
还没有评论，来说两句吧...