Choose a Linux database architecture by naming the problem first: keeping a service available, recovering after a site failure, or processing more work. IBM Db2 offers several approaches, and a cluster diagram becomes useful when it explains what happens to data and client requests during a failure.
This guide is for administrators and application owners evaluating Db2 on Linux. It provides a decision and validation framework; use IBM's documentation for the exact Db2 release, platform, edition and licensed features when designing an installation. The DB2 ICE era of the early 2000s helped establish Linux database clusters, but current decisions require a fresh inventory of the actual workload.
Write the service requirement first
Describe the important transaction in ordinary language: an order is accepted, an account balance is read, or a report finishes before a deadline. Define recovery time objective (RTO) as the target maximum time to restore the required service, and recovery point objective (RPO) as the target maximum amount of data loss expressed in time. Measure the recovery outcome against those targets in a rehearsal.
A database that is running while clients cannot reconnect has not restored the service. Include DNS or endpoint changes, credentials, application retries, data reconciliation and operator decisions in the recovery clock. State whether the scenario is a failed process, a lost host, a storage outage or a whole site becoming unavailable.
Compare how the data is organized
On a small screen, scroll the table sideways to read all columns.
| Approach | Basic arrangement | Question to resolve |
|---|---|---|
| HADR | A primary database sends logs to one or more standbys that maintain recoverable copies. | How much lag is acceptable, and how will applications reach the new primary? |
| pureScale | Multiple members access a shared database, coordinated with cluster caching facilities. | Does the complete shared-storage and cluster design meet the workload and failure requirements? |
| Database Partitioning Feature (DPF) | Database partitions divide data and processing; multiple partitions may reside on one or more hosts. | Will the distribution key and query pattern spread work effectively? |
IBM's pureScale component description explains members, cluster caching facilities, shared storage and cluster services. A shared database needs coordinated access and failure handling. Additional members also need enough capacity to carry useful work when a member is unavailable.
The Db2 12.1.2 Partitioning and Clustering Guide distinguishes database partitioning from table partitioning. Dividing a table into ranges for management is a different decision from distributing database work across partitions. For DPF, inspect data skew and joins: a hot key or frequent redistribution can leave a nominally large cluster waiting on one busy part.
Understand what a committed transaction has reached
HADR's synchronization mode changes the relationship between primary commit and standby log delivery. In IBM's synchronization-mode explanation, SYNC waits for the relevant log records to reach disk on both sides; NEARSYNC waits for primary disk and standby memory; ASYNC waits for primary disk and delivery to the primary's TCP layer; SUPERASYNC allows primary log writing to proceed independently of replication.
Those choices trade response time against protection in particular failure scenarios. Review the current replication state, log gap and behavior during disconnection as well as the configured mode. A mode name alone cannot guarantee an RPO in every outage. For multiple standbys, IBM documents different roles and synchronization constraints for principal and auxiliary standbys.
Replication can carry an unwanted application change to another copy. Maintain a separately protected backup and log-retention plan, and rehearse restoring the required recovery point. Decide who is authorized to promote a standby, how the previous primary is prevented from accepting conflicting writes, and how the cluster is re-established afterward.
Check the complete supported combination
Record Db2 version and fix level, Linux distribution and release, processor architecture, storage, network design, cluster manager, client drivers and virtualization environment. Check IBM's Db2 system requirements and the separate pureScale installation planning guidance. Requirements for one topology should not be carried into another by assumption.
Ask the responsible supplier to confirm feature entitlement and the proposed production configuration. Keep the answer with the design record. Include patching, certificate renewal, monitoring, backup destinations and on-call ownership in the operating plan; these duties continue after the cluster starts successfully.
Test recovery through a client transaction
- Load representative test data and capture baseline throughput, latency and correctness.
- Introduce one documented failure in a nonproduction environment. Record the time the client first loses the required service.
- Observe detection, arbitration, recovery and client reconnection. Verify acknowledged transactions and application-level invariants.
- Measure recovery to a successful representative transaction. Record any manual action and any data requiring reconciliation.
- Restore normal redundancy and repeat the backup restore test separately.
Use the downloadable record to document both requirements and observations. Keep a failed test as evidence of a design or operating gap, then revise and repeat the affected scenario.
Keep a working record
Download the db2 architecture and recovery record (plain text). Save a copy and fill in the evidence for your own task.