Restore Primary region preserving disaster recovery changes

This scenario verifies that activity performed in the secondary region during DR operations is preserved when restoring the cluster back to the primary region.

This includes:

User activity
Audit logs
Semantic model processes
Login history

Enable Bidirectional S3 Replication

Using the AWS Console, configure replication from the secondary region bucket (Region-B) back to the primary region bucket (Region-A). For more details, see AWS documentation.

Some paths must be excluded from replication.

Required Prefixes

user/engine_work/cubes/
user/engine_work/data/
user/engine_work/jars/
user/engine_work/kyvos-k8s/
user/engine_work/logs/
user/engine_work/olapengine/
user/engine_work/resultcache/
user/engine_work/spark_archive/

Note

AWS currently does not support direct exclusion rules for replication.
Therefore, individual prefixes must be defined. If new directories are introduced inside engine_work in future releases, they must be added to the replication configuration.

Verification Workflow

In Region-A, create a replica of the Kyvos RDS instance from Region-B.
After verification in Region-B, stop Kyvos services and Kyvos Manager.
Stop all Region-B resources.
Start the original Region-A resources.
Promote the RDS replica created earlier.
Start Kyvos Manager in Region-A.
Stop Kyvos services.
Use Switch Repository in Kyvos Manager and configure the promoted RDS instance as the Kyvos repository.
Start Kyvos services.
Perform sanity checks and cube builds.

Important behavior

After restoration:

The following are preserved from Region-B

User accounts
Login history
Audit logs
Cube build history
Incremental semantic model jobs

The following are NOT RESTORED

Configuration changes performed after DR
Any configuration changes in Kyvos from Kyvos Manager, such as SMTP, TLS, and Properties related changes.
Connections created in Region B from Kyvos.