The database files that need to be archived in order to recover the database from catastrophic failure. Database files that have not been accessed during the lifetime of the current log files are not included in this list. It is also possible that some of the files referred to by the log have since been deleted from the system.

The names of all of the log files that are no longer in use (for example, that are no longer involved in active transactions), and that may safely be archived for catastrophic recovery and then removed from the system.

Perform a hot back up of the open environment.

All files used by the environment are backed up, so long as the normal rules for file placement are followed. For information on how files are normally placed relative to the environment directory, see the "Berkeley DB File Naming" section in the Berkeley DB Reference Guide.

By default, data directories and the log directory specified relative to the home directory are recreated relative to the target directory. If absolute path names are used, then use the SingleDir method.

This method provides the same functionality as the db_hotbackup utility. However, this method does not perform the housekeeping actions performed by that utility. In particular, you may want to run a checkpoint before calling this method. To run a checkpoint, use the Checkpoint()()() method. For more information on checkpoints, see the "Checkpoint" section in the Berkeley DB Reference Guide.

To back up a single database file within the environment, use the BackupDatabase(String, String, Boolean) method.

In addition to the configuration options available using the BackupOptions class, additional tuning modifications can be made using the BackupReadCount, BackupReadSleepDuration, BackupBufferSize, and BackupWriteDirect properties. Alternatively, you can write your own custom hot back up facility using the IBackup interface.

Perform a hot back up of a single database file contained within the environment.

To back up the entire environment, use the Backup(String, BackupOptions) method.

You can make some tuning modifications to the backup process using the BackupReadCount, BackupReadSleepDuration, BackupBufferSize, and BackupWriteDirect properties. Alternatively, you can write your own custom hot back up facility using the IBackup interface.

Allocate a locker ID in an environment configured for Berkeley DB Concurrent Data Store applications.

By closing the Berkeley DB environment you can free allocated resources and close any open databases along with the underlying subsystems.

Close the Berkeley DB environment, freeing any allocated resources, closing any open databases as well as underlying subsystems.

Close the Berkeley DB environment, freeing any allocated resources, closing any open databases as well as underlying subsystems.

Close the Berkeley DB environment, freeing any allocated resources, closing any open databases as well as underlying subsystems.

Run one iteration of the deadlock detector. The deadlock detector traverses the lock table and marks one of the participating lock requesters for rejection in each deadlock it finds.

Determines whether the specified Object is equal to the current Object.

Check for threads of control (either a true thread or a process) that have exited while manipulating Berkeley DB library data structures, while holding a logical database lock, or with an unresolved transaction (that is, a transaction that was never aborted or committed).

Serves as a hash function for a particular type.

Gets the Type of the current instance.

This method checks to see if a specified transaction has been replicated from the master of a replication group. It may be called by applications using either the Base API or the Replication Manager.

Map an LSN object to a log filename

The names of all of the log files

Verify log records of this environment.

Append a record to the log

Instantiate a new DatabaseEnvironment object and open the Berkeley DB environment represented by home.

Set the panic state for the database environment. (Database environments in a panic state normally refuse all attempts to call Berkeley DB functions, throwing RunRecoveryException.)

Restore transactions that were prepared, but not yet resolved at the time of the system shut down or crash, to their state prior to the shut down or crash, including any locks previously held.

The amount of memory to be used by shared structures in the main environment region. These are structures other than mutexes and the page cache (memory pool).

The environment regions, including any backing files, are removed. Any log or database files and the environment directory are not removed.

If there are processes that have called Open(String, DatabaseEnvironmentConfig) without calling Close()()() (that is, there are processes currently using the environment), Remove fails without further action.

Calling Remove should not be necessary for most applications because the Berkeley DB environment is cleaned up as part of normal database recovery procedures. However, applications may want to call Remove as part of application shut down to free up system resources. For example, if SystemMemory was specified to Open(String, DatabaseEnvironmentConfig), it may be useful to call Remove in order to release system shared memory segments that have been allocated. Or, on architectures in which mutexes require allocation of underlying system resources, it may be useful to call Remove in order to release those resources. Alternatively, if recovery is not required because no database state is maintained across failures, and no system resources need to be released, it is possible to clean up an environment by simply removing all the Berkeley DB files in the database environment's directories.

In multithreaded applications, only a single thread may call Remove.

Remove log files that are no longer needed. Automatic log file removal is likely to make catastrophic recovery impossible.

RepHoldElection is not called by most replication applications. It should only be called by applications implementing their own network transport layer, explicitly holding replication group elections and handling replication messages outside of the replication manager framework.

If the election is successful, Berkeley DB notifies the application of the results of the election by means of either the REP_ELECTED or REP_NEWMASTER events (see EventNotifyfor more information). The application is responsible for adjusting its relationship to the other database environments in the replication group, including directing all database updates to the newly selected master, in accordance with the results of the election.

The thread of control that calls RepHoldElection must not be the thread of control that processes incoming messages; processing the incoming messages is necessary to successfully complete an election.

Before calling this method, the RepTransport delegate must already have been configured to send replication messages.

Create DbChannel with given eid.

Set a byte-count limit on the maximum amount of dynamic memory used by the Replication Manager incoming queue.

Configure a site in the replication manager.

There are two ways to build Berkeley DB replication applications: the most common approach is to use the Berkeley DB library "replication manager" support, where the Berkeley DB library manages the replication group, including network transport, all replication message processing and acknowledgment, and group elections. Applications using the replication manager support generally make the following calls:

1. Configure the local site in the replication group, RepMgrLocalSite.
2. Call RepMgrSiteConfig(DbSiteConfig) to configure the remote site(s) in the replication group.
3. Configure the message acknowledgment policy (RepMgrAckPolicy) which provides the replication group's transactional needs.
4. Configure the local site's election priority, RepPriority.
5. Call RepMgrStartClient(Int32) or RepMgrStartMaster(Int32) to start the replication application.

For more information on building replication manager applications, please see the Replication Getting Started Guide included in the Berkeley DB documentation.

Applications with special needs (for example, applications using network protocols not supported by the Berkeley DB replication manager), must perform additional configuration and call other Berkeley DB replication methods. For more information on building advanced replication applications, please see the Base Replication API section in the Berkeley DB Programmer's Reference Guide for more information.

Starting the replication manager consists of opening the TCP/IP listening socket to accept incoming connections, and starting all necessary background threads. When multiple processes share a database environment, only one process can open the listening socket; RepMgrStartClient(Int32) (and RepMgrStartMaster(Int32)) automatically open the socket in the first process to call it, and skips this step in the later calls from other processes.

Start the replication manager as a master site, and do not call for an election.

Process an incoming replication message sent by a member of the replication group to the local database environment.

Set the clock skew ratio among replication group members based on the fastest and slowest measurements among the group for use with master leases.

Set a threshold for the minimum and maximum time that a client waits before requesting retransmission of a missing message.

Set a byte-count limit on the amount of data that is transmitted from a site in response to a single message processed by RepProcessMessage(DatabaseEntry, DatabaseEntry, Int32). The limit is not a hard limit, and the record that exceeds the limit is the last record to be sent.

Initialize the communication infrastructure for a database environment participating in a replicated application.

RepStartClient is not called by most replication applications. It should only be called by applications implementing their own network transport layer, explicitly holding replication group elections and handling replication messages outside of the replication manager framework.

Replication master environments are the only database environments where replicated databases may be modified. Replication client environments are read-only as long as they are clients. Replication client environments may be upgraded to be replication master environments in the case that the current master fails or there is no master present. If master leases are in use, this method cannot be used to appoint a master, and should only be used to configure a database environment as a master as the result of an election.

Before calling this method, the RepTransport delegate must already have been configured to send replication messages.

RepStartMaster is not called by most replication applications. It should only be called by applications implementing their own network transport layer, explicitly holding replication group elections and handling replication messages outside of the replication manager framework.

Replication master environments are the only database environments where replicated databases may be modified. Replication client environments are read-only as long as they are clients. Replication client environments may be upgraded to be replication master environments in the case that the current master fails or there is no master present. If master leases are in use, this method cannot be used to appoint a master, and should only be used to configure a database environment as a master as the result of an election.

Before calling this method, the RepTransport delegate must already have been configured to send replication messages.

Force master synchronization to begin for this client.

Allow database files to be copied and used in the same database environment as the original.

Allow database files to be moved from one transactional database environment to another.

Limit the number of sequential write operations scheduled by the library when flushing dirty pages from the cache.

Returns a String that represents the current Object.

Ensure that a specified percent of the pages in the cache are clean, by writing dirty pages to their backing files.

WriteToLog allows applications to include information in the database environment log files, for later review using the db_printlog utility. This method is intended for debugging and performance tuning.

WriteToLog allows applications to include information in the database environment log files, for later review using the db_printlog utility. This method is intended for debugging and performance tuning.

If true, database operations for which no explicit transaction handle was specified, and which modify databases in the database environment, are automatically enclosed within a transaction.

The size of the buffer, in bytes, to read from the database during a hot backup.

Sets the IBackup interface to be used when performing hot backups.

This interface is used to override the default behavior used by the Backup(String, BackupOptions) and BackupDatabase(String, String, Boolean) methods.

The number of pages to read before pausing during the hot backup.

Increasing this value increases the amount of I/O the backup process performs for any given time interval. If your application is already heavily I/O bound, setting this value to a lower number may help to improve your overall data throughput by reducing the I/O demands placed on your system. By default, all pages are read without a pause.

The number of microseconds to sleep between batches of reads during a hot backup.

Increasing this value decreases the amount of I/O the backup process performs for any given time interval. If your application is already heavily I/O bound, setting this value to a higher number may help to improve your overall data throughput by reducing the I/O demands placed on your system.

If true, direct I/O is used when writing pages to the disk during a hot backup.

For some environments, direct I/O can provide faster write throughput, but usually it is slower because the OS buffer pool offers asynchronous activity.

Deprecated. Replaced by ExternalFileDir.

Deprecated. Replaced by ExternalFileThreshold.

The size of the shared memory buffer pool (the cache).

If true, Berkeley DB Concurrent Data Store applications perform locking on an environment-wide basis rather than on a per-database basis.

If true, Berkeley DB subsystems create any underlying files, as necessary.

The array of directories where database files are stored.

The deadlock detector configuration, specifying which lock request(s) should be rejected. As transactions acquire locks on behalf of a single locker ID, rejecting a lock request associated with a transaction normally requires the transaction to be aborted.

The algorithm used by the Berkeley DB library to perform encryption and decryption.

The mechanism for reporting detailed error messages to the application.

The prefix string that appears before error messages issued by Berkeley DB.

A delegate which is called to notify the process of specific Berkeley DB events.

The path of the directory where external files are stored.

The size in bytes which is used to determine when a data item is stored as an external file.

Any data item that is equal to or larger in size than the threshold value is automatically stored as an external file.

If the threshold value is 0, databases opened in the environment default to never using external file support.

Monitor progress within long running operations.

If true, flush database writes to the backing disk before returning from the write system call, rather than flushing database writes explicitly in a separate system call, as necessary.

If true, the object is free-threaded; that is, concurrently usable by multiple threads in the address space.

The database environment home directory.

Whether there is any hot backup in progress.

The number of databases initialized when the environment is created

The maximum length of database's directory and name strings initialized when the environment is created

The number of databases and subdatabases using external files initialized when the environment is created

The number of locks allocated when the environment is created

The number of lockers allocated when the environment is created

The number of lock objects allocated when the environment is created

The number of log identifier objects allocated when the environment is created

The initial number of mutexes allocated

If true, Berkeley DB page-faults shared regions into memory when initially creating or joining a Berkeley DB environment.

The maximum number of replication sites initialized when the environment is created

The number of thread objects allocated when the environment is created

The number of transaction objects allocated when the environment is created

The intermediate directory permissions.

The current lock conflicts array.

If true, lock shared Berkeley DB environment files and memory-mapped databases into memory.

The number of lock table partitions used in the Berkeley DB environment.

The size of the lock table in the Berkeley DB environment.

A value, in microseconds, representing lock timeouts.

If true, Berkeley DB automatically removes log files that are no longer needed.

Deprecated. Replaced by LogExternalFileContent

The size of the in-memory log buffer, in bytes

The path of a directory to be used as the location of logging files. Log files created by the Log Manager subsystem are created in this directory.

If true, enables full logging of external file data. Required if using HA or the hotbackup utility.

The absolute file mode for created log files. This property is only useful for the rare Berkeley DB application that does not control its umask value.

If true, Berkeley DB flushes log writes to the backing disk before returning from the write system call, rather than flushing log writes explicitly in a separate system call, as necessary.

If true, transaction logs are maintained in-memory rather than on disk. This means that transactions exhibit the ACI (atomicity, consistency, and isolation) properties, but not D (durability).

If true, system buffering is turned off for Berkeley DB log files to avoid double caching.

If true, Berkeley DB avoids the fsync() call when the log files are flushed.

The size of the underlying logging area of the Berkeley DB environment, in bytes.

If true, all pages of a log file are zeroed when that log file is created.

The maximum cache size

The maximum number of locking entities supported by the Berkeley DB environment.

The maximum number of locks supported by the Berkeley DB environment.

The maximum size of a single file in the log, in bytes. Because LSN Offsets are unsigned four-byte values, the size may not be larger than the maximum unsigned four-byte value.

The total number of mutexes allocated

The maximum number of locked objects

The number of file descriptors the library opens concurrently when flushing dirty pages from the cache.

The number of sequential write operations scheduled by the library when flushing dirty pages from the cache.

The number of active transactions supported by the environment. This value bounds the size of the memory allocated for transactions. Child transactions are counted as active until they either commit or abort.

The mechanism for reporting detailed statistic messages to the application.

The prefix string that appears before informational messages issued by Berkeley DB.

The path of directory to store the persistent metadata.

The maximum file size, in bytes, for a file to be mapped into the process address space. If no value is specified, it defaults to 10MB.

The message file.

The mutex alignment, in bytes.

The number of additional mutexes allocated.

If true, turn off system buffering of Berkeley DB database files to avoid double caching.

If true, Berkeley DB grants all requested mutual exclusion mutexes and database locks without regard for their actual availability. This functionality should never be used for purposes other than debugging.

If true, Berkeley DB copies read-only database files into the local cache instead of potentially mapping them into process memory.

If true, Berkeley DB ignores any panic state in the database environment. (Database environments in a panic state normally refuse all attempts to call Berkeley DB functions, throwing RunRecoveryException.) This functionality should never be used for purposes other than debugging.

The number of times that test-and-set mutexes should spin without blocking. The value defaults to 1 on uniprocessor systems and to 50 times the number of processors on multiprocessor systems.

If true, overwrite files stored in encrypted formats before deleting them.

If true, allocate region memory from the heap instead of from memory backed by the filesystem or system shared memory.

The path of a directory to be used as the location of region files. Region files created by the Environment are stored in this directory.

The bytes component of the byte-count limit on the amount of memory to be used by shared structures in the main environment region. These are the structures other than mutexes and the page cache (memory pool).

The gigabytes component of the byte-count limit on the amount of memory to be used by shared structures in the main environment region. These are the structures other than mutexes and the page cache (memory pool).

If true, Berkeley DB checks if recovery is needed to be performed before opening the database environment.

The amount of time the replication manager's transport function waits to collect enough acknowledgments from replication group clients, before giving up and returning a failure indication. The default wait time is 1 second.

If true, the replication master automatically re-initializes outdated clients (defaults to true).

If true, the replication master sends groups of records to the clients in a single network transfer

The amount of time a master site delays between completing a checkpoint and writing a checkpoint record into the log.

The value, relative to RepClockskewSlow, of the fastest clock in the group of sites.

The value of the slowest clock in the group of sites.

The amount of time the replication manager waits before trying to re-establish a connection to another site after a communication failure. The default wait time is 30 seconds.

If true, the client should delay synchronizing to a newly declared master (defaults to false). Clients configured in this way remain unsynchronized until the application calls RepSync()()().

This flag is used to prevent the use of poll() as polling method for networking events on the target site. This flag guarantees that instead of poll() select or epoll() would be used depending on the availablity of these methods on the target platform and additional flags provided to repmgr.

This flag is used to prevent the use of SSL for securing the messages exchanged between nodes in a replication group.

Configure the amount of time the replication manager waits before retrying a failed election. The default wait time is 10 seconds.

The timeout period for an election. The default timeout is 2 seconds.

This flag is used to force the use of epoll as polling method for networking events instad of poll or select. Use of this flag does not guarantee that epoll will be used though. It depends on the availability of epoll on target platform. Epoll is supposed to be used only when the expected number of connections for repmgr is greater than 1000.

Enable simple write forwarding for this site. By default, write operations cannot be performed on a replication client site. This option enables forwarding of simple client put and delete operations to the master site for processing. These operations must use an implicit NULL transaction ID to be forwarded. Any other write operation that specifies a non-NULL transaction throws a DatabaseException. The master must have an open database handle for the database on which a forwarded write operation is being performed. All sites in the replication group should have the same value for this configuration option.

An optional configuration timeout period to wait for full election participation the first time the replication group finds a master. By default this option is turned off and normal election timeouts are used. (See the Elections section in the Berkeley DB Reference Guide for more information.)

The amount of time the replication manager, running at a client site, waits for some message activity on the connection from the master (heartbeats or other messages) before concluding that the connection has been lost. When 0 (the default), no monitoring is performed.

The frequency at which the replication manager, running at a master site, broadcasts a heartbeat message in an otherwise idle system. When 0 (the default), no heartbeat messages are sent.

If true, replication only stores the internal information in-memory and cannot keep persistent state across a site crash or reboot. By default, it is false and replication creates files in the environment home directory to preserve the internal information.

The amount of time a client grants its master lease to a master. When using master leases all sites in a replication group must use the same lease timeout value. There is no default value. If leases are desired, this method must be called prior to calling RepStartClient()()() or RepStartMaster()()().

The function used to create a replication view that determines whether a database file is replicated to the local site.

Set the message dispatch function. It is responsible for receiving messages sent from remote sites using either SendMessage(array<DatabaseEntry>[]()[]) or SendRequest(array<DatabaseEntry>[]()[], UInt32). If the message received by this function was sent using SendMessage(array<DatabaseEntry>[]()[]), then no response is required. If the message was sent using SendRequest(array<DatabaseEntry>[]()[], UInt32), then this function must send a response using SendMessage(array<DatabaseEntry>[]()[]).

Specify how master and client sites handle acknowledgment of replication messages which are necessary for "permanent" records. The current implementation requires all sites in a replication group configure the same acknowledgement policy.

The bytes component of the maximum amount of dynamic memory used by the Replication Manager incoming queue.

The gigabytes component of the maximum amount of dynamic memory used by the Replication Manager incoming queue.

The local site of the replication manager. Returns null if the local site has not been configured.

The status of the sites currently known by the replication manager.

If true, Replication Manager automatically runs elections to choose a new master when the old master disconnects (defaults to true).

If true, errors are returned immediately for Berkeley DB method calls that would normally block while clients are in recovery (defaults to false).

The total number of sites in the replication group.

This flag is used to specify the client site in a replication group operating in preferred master mode. A preferred master replication group must contain only two sites, with one site specified as the preferred master site and the other site specified as the client site. The client site in a preferred master replication group takes over temporarily as master when the preferred master site is unavailable.

This flag is used to specify the preferred master site in a replication group operating in preferred master mode. A preferred master replication group must contain only two sites, with one site specified as the preferred master site and the other site specified as the client site. The preferred master site operates as the master site whenever possible.

The database environment's priority in replication group elections. A special value of 0 indicates that this environment cannot be a replication group master. If not configured, then a default value of 100 is used.

The maximum number of microseconds a client waits before requesting retransmission.

The minimum number of microseconds a client waits before requesting retransmission.

Replication Manager observes the strict "majority" rule in managing elections, even in a group with only 2 sites. The client in a 2-site group is unable to take over as master if the original master fails or becomes disconnected. (See the Elections section in the Berkeley DB Reference Guide for more information.) Both sites in the replication group should have the same value for this parameter.

The bytes component of the byte-count limit on the amount of data that is transmitted from a site in response to a single message processed by RepProcessMessage(DatabaseEntry, DatabaseEntry, Int32).

The gigabytes component of the byte-count limit on the amount of data that is transmitted from a site in response to a single message processed by RepProcessMessage(DatabaseEntry, DatabaseEntry, Int32).

The delegate used to transmit data using the replication application's communication infrastructure.

If true, master leases are used for this site (defaults to false).

Configure the amount of time a Replication Manager client waits for a response from a forwarded write operation before returning a failure indication. The default value is 5 seconds.

If true, catastrophic recovery was run on this environment before opening it for normal use.

If true, normal recovery was run on this environment before opening it for normal use.

The number of microseconds the thread of control pauses before scheduling further write operations.

A delegate that returns a unique identifier pair for the current thread of control.

A delegate that formats a process ID and thread ID identifier pair.

If true, allocate region memory from system shared memory instead of from heap memory or memory backed by the filesystem.

The path of a directory to be used as the location for temporary files.

An approximate number of threads in the database environment.

A delegate that returns if a thread of control (either a true thread or a process) is still running.

If true, database calls timing out based on lock or transaction timeout values throw LockNotGrantedException instead of DeadlockException.

If true, Berkeley DB does not write or synchronously flush the log on transaction commit.

If true and a lock is unavailable for any Berkeley DB operation performed in the context of a transaction, cause the operation to throw DeadlockException (or LockNotGrantedException if configured with TimeNotGranted).

If true, all transactions in the environment are started as if Snapshot was passed to BeginTransaction()()(), and all non-transactional cursors are opened as if SnapshotIsolation was passed to Cursor()()().

A value, in microseconds, representing transaction timeouts.

The recovery timestamp

If true, Berkeley DB writes, but does not synchronously flush, the log on transaction commit.

The Berkeley DB process' environment may be permitted to specify information to be used when naming files; see Berkeley DB File Naming in the Programmer's Reference Guide for more information.

If true, all databases in the environment are opened as if UseMVCC was set.

If true, locking for the Berkeley DB Concurrent Data Store product was initialized.

If true, the locking subsystem was initialized.

If true, the logging subsystem was initialized.

If true, the shared memory buffer pool subsystem was initialized.

If true, the replication subsystem was initialized.

If true, the transaction subsystem was initialized.

Specific additional informational and debugging messages in the Berkeley DB message output.

If true, Berkeley DB yields the processor immediately after each page or mutex acquisition.