Replicating an Encrypted Database

TimesTen supports replication for encrypted databases. During a database duplicate operation (ttRepAdmin -duplicate), TimesTen reads the required keys to decrypt the checkpoint files and copies the wallet to the path specified by the DbKeyWallet attribute of the database targeted as a duplicate.

To replicate an encrypted database, it is mandatory to have consistent TLS configuration between TimesTen instances (replication peers), that is, the cipher suites and replication wallet settings between replication peers must match and be explicitly required to match. See Task 3: Configure TLS for Replication.

WARNING:

Encryption attempts for an unencrypted database fail if the replication agent is already running. Ensure that you stop the replication agent before attempting to encrypt an unencrypted database.

TimesTen records rekey requests in the transaction log file. The replication agent replicates the rekey operation on standby or subscriber databases once it reads the transaction log file.

  • For active standby pair replication, you can only issue a rekey request on the active database.

  • For classic replication, you can only issue a rekey request on a master database. However, unlike with a single active database, it is possible for two separate masters to issue concurrent rekey requests. This may happen if there is some kind of delay due to network partition or one of the replication agents being down. In this case, to avoid conflicts with concurrent rekey requests that change the encryption algorithm, master database A only needs to replicate a rekey request from master database B if the request from B has a newer time stamp than the last request from A and vice versa.

For an example on how to set up replication for an encrypted database, see Configuring an Active Standby Pair with One Subscriber or Configuring a Classic Replication Scheme with One Master and One Subscriber in Oracle TimesTen In-Memory Database Replication Guide while taking into account Example 3-2 and Example 3-3 for step 1 and step 2, respectively.

Example 3-2 DSN Specification for an Active Standby Pair Replication Scheme for Encrypted Databases

This is an example of a DSN specification for a set of databases in an active standby pair with one subscriber configuration. Encryption at rest is enabled and set to use the AES-256 encryption algorithm upon database creation. The wallet for the master key is set to be stored within the /disk1/wallets directory. 

[master1]
DataStore=/disk1/databases/master1
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8
DbEncrypted=AES256
DbKeyWallet=/disk1/wallets

[master2]
DataStore=/disk1/databases/master2
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8
DbEncrypted=AES256
DbKeyWallet=/disk1/wallets

[subscriber1]
DataStore=/disk1/databases/subscriber1
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8
DbEncrypted=AES256
DbKeyWallet=/disk1/wallets

Example 3-3 Required Parameters in the TimesTen Instance Configuration File for Replication of Encrypted Databases

This is an example of the required parameters in the TimesTen instance configuration file (timesten.conf) for replication of encrypted databases. 

replication_wallet=/disk1/wallets/serverWallet
replication_cipher_suite=TLS_AES_256_GCM_SHA384
replication_ssl_mandatory=1

Where:

  • replication_wallet is the absolute path to the server wallet.

  • replication_cipher_suite is the cipher suite to be used for encrypted communication between replication agents.

  • replication_ssl_mandatory specifies whether it is mandatory to have consistent TLS configuration between replication peers. 1 indicates that replication cannot proceed unless TLS settings match on all TimesTen instances.