On-Premises Oracle RAC Replacement_ HA Validation Steps

Architectural Parity: Shared-Storage vs. Shared-Disk Models

Oracle RAC relies on a shared-disk architecture where multiple instances access the same storage subsystem via a cluster file system or ASM (Automatic Storage Management). This model requires sophisticated cache fusion protocols to maintain data consistency across nodes. In contrast, KingbaseES implements a shared-storage RAC clustering architecture. While the physical storage layer is similar, the internal coordination and file management differ significantly.

Understanding this distinction is critical for migration planning. Oracle’s shared-disk model tightly couples the storage layer with the instance management. KingbaseES shared-storage clusters decouple some of these dependencies, relying on a control file and configuration parameters to manage node states. This architectural shift affects how you configure network interfaces, manage storage latency, and validate data consistency during cutover.

The primary risk in migration is assuming identical behavior between these models. Oracle-specific features such as DBMS_PARALLEL_EXECUTE or RAC-specific hints may require refactoring. The validation phase must confirm that the shared-storage model provides equivalent ACID compliance and transaction isolation levels.

Prerequisites for On-Premises Shared-Storage Deployment

Before initiating the migration, the on-premises infrastructure must meet specific hardware and network requirements to support the shared-storage architecture. Unlike shared-nothing architectures, shared-storage clusters are highly sensitive to storage latency and network bandwidth.

Infrastructure Checklist

1. Storage Subsystem: Deploy low-latency SAN, NFS, or iSCSI storage. Ensure consistent IOPS across all cluster nodes. Verify that the storage array supports concurrent multi-writer access if required by the specific clustering mode.
2. Network Configuration: Configure a dedicated private network for cluster interconnect traffic. This network must have low latency and high bandwidth to handle lock management and data synchronization. Ensure NTP (Network Time Protocol) is synchronized across all nodes to prevent timestamp discrepancies.
3. OS and Kernel Parameters: Adjust kernel parameters for shared memory, semaphores, and file descriptors. These settings are critical for handling high-concurrency transactions typical in RAC replacements. Note: Specific kernel parameter names (e.g., shmmax, semmsl) and values must be verified against the official KingbaseES documentation for your target version, as defaults may differ from Oracle recommendations.
4. Licensing and Compliance: Ensure commercial licenses for KingbaseES are procured and valid. Verify that the on-premises deployment complies with local data residency requirements.

Migration Strategy: Phased Implementation and Refactoring

Migrating from Oracle RAC to a commercial alternative requires a phased approach to mitigate application compatibility risks. The strategy focuses on data synchronization, schema conversion, and application code refactoring.

Phased Implementation Steps

1. Assessment and Gap Analysis:

   • Audit the existing Oracle RAC application code for Oracle-specific features (e.g., PL/SQL packages, RAC hints, specific data types).
   • Identify features that require refactoring or replacement in KingbaseES.
   • Document the current data volume and growth rate to size the target cluster appropriately.

2. Schema and Data Migration:

   • Use supported migration methodologies or ETL processes to convert schema definitions. Note: Specific vendor-supported migration tools should be verified against the KingbaseES documentation for your target version.
   • Perform an initial full data load to the new KingbaseES cluster.
   • Establish a continuous replication or CDC (Change Data Capture) mechanism to keep the target cluster synchronized with the source Oracle RAC during the migration window.

3. Application Refactoring:

   • Update application connection strings to point to the new cluster.
   • Refactor PL/SQL code to use compatible SQL dialects or KingbaseES equivalents.
   • Conduct unit and integration testing to ensure application logic remains intact.

4. Cutover Planning:

   • Schedule the cutover during a maintenance window with minimal business impact.
   • Prepare a rollback plan in case of critical failures during the switch.
   • Communicate the downtime expectations to stakeholders clearly.

Warning: Specific migration scripts or commands are not universally applicable. Always test migration tools in a staging environment that mirrors production hardware. Do not proceed with cutover without verifying data integrity in the staging phase.

Validating Failover and Availability: The HA Testing Solution

The core of the migration success lies in validating that the new cluster can handle failures without data loss or extended downtime. KingbaseES provides a High Availability Testing Solution designed to verify failover behavior and system availability across different deployment architectures. This solution helps systematically validate the overall availability of the product, aiming for fault-free operation and optimized operational costs.

Verification Procedure

1. Pre-Test Validation:

   • Ensure all cluster nodes are healthy and synchronized.
   • Verify that the control file is correctly configured. Note: The control file is automatically updated when kingbase.conf parameters are modified, but manual verification of cluster status is recommended.

2. Node Failure Simulation:

   • Simulate a node failure by stopping the database service or shutting down the node using KingbaseES cluster management commands (e.g., sys_ctl stop).
   • Monitor the cluster manager to ensure automatic failover to a healthy node occurs.
   • Verify that client connections are re-established automatically or via connection pooling.

3. Network Partition Testing:

   • Simulate a network partition between nodes.
   • Check if the cluster correctly identifies the partitioned node and continues serving requests from the remaining nodes.
   • Ensure that no split-brain scenarios occur where multiple nodes claim primary status.

4. Data Consistency Check:

   • After failover, verify that no data was lost during the transition.
   • Run integrity checks on critical tables to ensure ACID compliance was maintained.
   • Compare transaction logs between the failed node (if recoverable) and the new primary to confirm consistency.

5. Recovery and Rejoining:

   • Restart the failed node and verify that it rejoins the cluster as a secondary or standby node.
   • Ensure that the node synchronizes any missing transactions during the downtime.

Verification Check: If failover times exceed acceptable thresholds or data inconsistencies are detected, do not proceed to production. Investigate the root cause in the staging environment.

Disaster Recovery Configuration: AlwaysOn and Sharding

For enterprise-grade resilience, local and multi-center disaster recovery (DR) configurations are essential. KingbaseES offers robust DR options, but it is crucial to use supported and future-proof architectures.

Local Disaster Recovery

For local DR, KingbaseES provides AlwaysOn Availability Groups. This is the recommended approach for high availability within the same data center or availability zone.

• Configuration: Set up a primary instance with one or more secondary instances. Configure the AlwaysOn Availability Group to handle automatic failover if the primary node becomes unavailable.
• Deprecation Warning: KingbaseRWC (Database Mirroring) is deprecated. Do not use KingbaseRWC for new deployments. AlwaysOn Availability Groups are the supported standard for local mirroring and failover.

Multi-Center Disaster Recovery

For geographic redundancy, KingbaseES supports multi-center disaster recovery via KingbaseES Sharding. This architecture distributes data across multiple centers, ensuring business continuity even if an entire data center fails.

• Configuration: Deploy shards across different geographic locations. Configure synchronous replication to ensure data durability across centers.
• Considerations: Multi-center setups introduce network latency. Evaluate the impact on write performance and adjust replication settings accordingly.

Operational Efficiency: Automated Control File Maintenance

One of the key operational differentiators in KingbaseES is the automated maintenance of the control file. In many traditional clustering solutions, administrators must manually update control files or configuration registries when cluster parameters change. This manual process is error-prone and increases operational overhead.

In KingbaseES, the control file records static information generated during database creation and configuration information from kingbase.conf. If related parameters in kingbase.conf are modified, the control file is updated automatically without manual maintenance. This feature reduces the risk of configuration drift and simplifies cluster management.

Example: Configuration Update

When modifying cluster parameters:

1. Edit kingbase.conf to change a clustering parameter (e.g., max_connections or network settings).
2. Reload the configuration using the appropriate KingbaseES command (e.g., sys_ctl reload or the specific SQL function documented for your version). Note: Do not use PostgreSQL-specific commands like SELECT pg_reload_conf(); unless explicitly verified as supported in your KingbaseES version documentation.
3. The system automatically updates the control file to reflect the new configuration.
4. Verify the change by checking the cluster status.

This automation ensures that the cluster state remains consistent with the configuration files, reducing the likelihood of human error during routine maintenance.

Production Readiness Checklist

Before cutover, ensure the following criteria are met:

• Architecture Validation: Confirmed that shared-storage model meets performance and consistency requirements.
• HA Testing: Failover and network partition tests passed with no data loss.
• Data Integrity: Post-migration data checks confirm ACID compliance.
• Application Compatibility: All Oracle-specific features have been refactored or replaced.
• DR Configuration: AlwaysOn Availability Groups and Sharding are configured and tested.
• Operational Automation: Control file updates are verified to be automatic.
• Rollback Plan: A tested rollback procedure is documented and available.

Successful migration is defined by validated failover behavior and data integrity, not just software installation. By following this systematic verification process, enterprises can replace Oracle RAC with KingbaseES while maintaining high availability and operational efficiency.

FAQ

How does KingbaseES RAC (shared-storage) differ from Oracle RAC (shared-disk) in terms of architecture and migration complexity?

KingbaseES uses a shared-storage architecture, while Oracle RAC uses a shared-disk model. The primary difference lies in how data consistency and node coordination are managed. Oracle relies on cache fusion and ASM, whereas KingbaseES uses a control file and distributed lock manager. Migration complexity arises from these architectural differences, requiring careful validation of data consistency and potential refactoring of Oracle-specific features.

Is KingbaseRWC still supported, or should I use AlwaysOn Availability Groups for local disaster recovery?

KingbaseRWC (Database Mirroring) is deprecated. You should use AlwaysOn Availability Groups for local disaster recovery. AlwaysOn provides robust failover capabilities and is the supported standard for high availability in KingbaseES deployments.

How can I verify data integrity and failover behavior after replacing Oracle RAC with KingbaseES?

Use the KingbaseES High Availability Testing Solution to systematically verify failover scenarios. Simulate node failures and network partitions, then check for automatic failover, connection re-establishment, and data consistency. Ensure that the control file is correctly updated and that no data is lost during the transition.

💡 More Resources

If you would like to dive deeper into KingbaseES and its application practices across various industries, we have compiled the following official resources to help you get started quickly and develop and operate with efficiency:

• Kingbase Community: A one-stop interactive platform for technical exchanges, Q&A, and experience sharing—join forces with fellow DBAs and developers.
• Kingbase Solutions: One-stop full-stack database migration and cloud-native solutions, supporting smooth migration of multi-source heterogeneous data, ensuring high availability, real-time integration, and sustained high performance.
• Kingbase Case Studies: Real-world user scenarios and implementation outcomes, showcasing KingbaseES’s outstanding capabilities in high availability, high performance, and IT adaptation.
• Kingbase Documentation: Authoritative and comprehensive product manuals and technical guides, covering the entire lifecycle from installation and deployment to development, programming, and operations management.
• Free Download: Get the latest installation packages, drivers, tools, and patches, supporting multiple platforms and domestic chip architectures.
• Digital Construction Encyclopedia: Covers digital strategy planning, data integration, metrics management, database visualization applications, and more to empower enterprise digital transformation.

Open Source Resources:

• GitHub – Kingbase-docs: Kingbase documentation open-source repository—Stars and contributions are welcome.
• Gitee – Kingbase-docs: Domestic mirror repository for Kingbase documentation for faster access.

Welcome to explore the resources above and begin your Kingbase journey!