IBM Db2 on Linux — architecture and recovery record
Purpose: define a workload and record a nonproduction recovery rehearsal.
Use a separate copy for each topology and failure scenario.
Article: https://yenra.com/ibm-linux-database-clusters/
Prepared: September 15, 2026

REQUIREMENTS
Service owner / operator:
Representative client transaction and correctness invariant:
Failure scenario and assumed surviving components:
RTO target (seconds):
RPO target (seconds of data loss; define acknowledged transactions):
Acceptable latency / throughput under normal and degraded operation:

DESIGN EVIDENCE
Db2 release, fix level, edition and feature entitlement:
Linux distribution, release and architecture:
Topology: HADR / pureScale / DPF / combination:
Storage, network, cluster manager, client driver:
Exact vendor support documents and date checked:
Promotion authority, fencing/arbitration, client reroute:
Backup protection, retained logs and tested recovery point:
Monitoring and alert owner:

REHEARSAL
Test environment and data:
Client service lost at:
Detection / recovery / client reconnection events:
First validated representative transaction at:
Elapsed service recovery (seconds):
Acknowledged records checked; missing, duplicate or inconsistent records:
Observed data-loss window and method of measurement:
Manual interventions:
Return to normal redundancy verified:
Separate backup restore result:
Pass/fail against each target, gaps, owner and retest date:

FICTIONAL CALIBRATION EXAMPLE
RTO 120 s; database available at 45 s; client validation completes at 95 s.
Service recovery = 95 s. Margin = 120 - 95 = 25 s.
Data-loss target is a separate check; this timing does not prove it.

Primary references:
https://www.ibm.com/docs/en/db2/12.1.x?topic=environment-components-db2-purescale-feature
https://ibm.github.io/db2-hadr-wiki/hadrSyncMode.html
This worksheet is a planning aid, not an installation or failover command sequence.