Hologres V1.1 and later provide the multi-instance high-availability deployment mode for online production environments that require high availability. This deployment mode supports the isolation of faults and loads for high availability. This topic describes this deployment mode and how to configure it.

Present high-availability deployment with automatic recovery of a single instance

Hologres compute nodes (the worker nodes in the following figure) are scheduled like containers, and the resource manager performs regular health checks. When a compute node takes more than 1 minute to respond due to out-of-memory (OOM) errors or faults in hardware or software, the resource manager automatically starts a new compute node and migrates shards from the faulty compute node to the new node. For example, when Worker Node 3 responds late, the resource manager starts Worker Node 4 to replace Worker Node 3. This implements fast recovery. Data is stored in Apsara Distributed File System and does not need to be migrated between compute nodes. Compute nodes are lightweight and stateless to support fast recovery. By default, the single-instance deployment mode is enabled for each Hologres instance. When an exception occurs on a node, the node can automatically recover without the need for manual O&M. If a query operator attempts to access a node while the node is in automatic recovery, the query immediately fails. Hologres V1.1 and later use a new recovery mechanism that can recover nodes within about 1 minute, which is 5 to 10 times faster than earlier versions. Single-instance deployment

Multi-instance high-availability deployment

In single-instance deployment mode, faults are monitored in real time and faulty nodes are replaced for recovery. During node recovery, the service may be unavailable. In key business scenarios, a higher level high-availability solution is required to support the isolation of faults and loads. Hologres V1.1 and later use the multi-instance high-availability deployment mode in which storage is shared for the instances. In this deployment mode, the primary instance has full capabilities, including data reads and writes, and configuration of permissions and system parameters. Secondary instances are read-only. All operations are performed on the primary instance. The following figure shows the multi-instance high-availability deployment mode. Multi-instance deployment
  • Up to four read-only secondary instances can be configured for each primary instance. Resource configurations among the instances may be different, but not significantly. The shard count must be the same for all instances.
  • Each read-only secondary instance has an independent endpoint, and different read-only secondary instances serve different business scenarios. Endpoints can be used to isolate business scenarios.
  • All instances share the same data, access control configurations, and storage charges.
  • The memory status of instances is automatically synchronized in real time. The memory status of instances within the same region can be synchronized within milliseconds. The memory status is synchronized across instances and cannot be implemented on a finer-grained basis.
  • Instances do not share computing resources, and have their loads and faults isolated.
  • We recommend that you use the primary instance to write and process data, and use the read-only secondary instances for online analytical processing (OLAP) and online services.
  • The isolation of instances reduces conflicts between read and write loads, reduces overheads for locks and transactions, and significantly improves the robustness of nodes. In addition, the deployment of multiple read-only secondary instances implements high availability of nodes.

Configure multi-instance high-availability deployment

When you configure multi-instance high-availability deployment, take note of the following items:
  • Only Hologres instances whose version is V1.1 or later can be used as primary instances. If the version of your Hologres instance is earlier than V1.1, submit a ticket or join the Hologres DingTalk group for technical support.
  • You cannot access read-only secondary instances that are not associated with a primary instance.
  • A primary instance and its read-only secondary instances must be of the same version.
  • A primary instance and its read-only secondary instances must reside in the same region.

Policy of associating or disassociating read-only secondary instances

If you want to associate read-only secondary instances with or disassociate them from a primary instance as a RAM user, attach the AliyunHologresFullAccess policy to the RAM user. For more information about the policies that can be attached to a RAM user in Hologres, see Grant permissions on Hologres to RAM users.

Perform the following steps to configure multi-instance high-availability deployment:

  1. Create a read-only secondary instance.
    Notice The read-only secondary instance must reside in the same region as its primary instance.

    On the buy page of Hologres instances, set the Instance Type parameter to Read-only Secondary Instance. For more information, see Purchase a Hologres instance.

  2. Associate the read-only secondary instance with a primary instance.
    1. On the Instances page of the Hologres console, find the read-only secondary instance that you want to manage and click Associate in the Instance Type column.
      Associate
    2. In the Associate with Primary Instance dialog box, select a primary instance and click Associate.
      Associate with Primary Instance
  3. Use the instances.
    When you use the multi-instance high-availability deployment mode, take note of the following items:
    • The endpoint of the read-only secondary instance can be used to provide online services.
    • All operations such as creating tables and granting permissions to users must be performed on the primary instance. Only data reads can be performed on the read-only secondary instance.
    • The read-only secondary instance automatically inherits all objects such as users and tables of the primary instance. Users cannot be separately created for the read-only secondary instance.