Scale-In with MariaDB Xpand

MariaDB Xpand can be scaled in, which reduces the number of Xpand nodes in the cluster.

The system variables, system tables, and ALTER CLUSTER statements referenced on this page are only available on the Xpand nodes. When using the Xpand Storage Engine topology, you need to connect to an Xpand node to use these features.

Use Cases

Some use cases for scale-in:

  • To reduce operating costs following a peak event (i.e., following Cyber-Monday).

  • To allocate servers for other purposes.

  • To remove failing hardware. (See ALTER CLUSTER DROP to drop a permanently failed node.)

Review Target Cluster Configuration

  • MariaDB Xpand requires a minimum of three nodes to support production systems. Going from three or more nodes to a single node is not supported via the steps outlined on this page.

  • When Zones are configured, Xpand requires a minimum of 3 zones.

  • For deployments deployed in zones, Xpand requires an equal number of nodes in each zone.

  • Ensure that the target deployment configuration has has sufficient space. See Allocating Disk Space for Fault Tolerance and Availability.

Scale-In

  1. Initiate Soft Fail:

    Marking a node as softfailed directs the Xpand Rebalancer to move all data from the node(s) specified to others within the deployment. The Rebalancer proceeds in the background while the database continues to serve your ongoing production needs.

    If necessary, determine the instance_id assigned to a given IP or hostname by running the following SELECT statement:

    SELECT * FROM system.nodeinfo ORDER BY instance_id;
    

    To initiate a Soft Fail, using ALTER CLUSTER:

    ALTER CLUSTER SOFTFAIL instance1, instance2;
    

    The SOFTFAIL operation will issue an error if there is not sufficient space to complete the softfail or if the softfail would leave the deployment unable to protect data should an additional node be lost.

    To cancel a Soft Fail process before it completes, use the following syntax. Your system will be restored to its prior configuration.

    ALTER CLUSTER UNSOFTFAIL instance1, instance2;
    
  2. Monitor the SOFTFAIL Process

    Once marked as softfailed, the Rebalancer moves data from the softfailed node(s). The Rebalancer process runs in the background while foreground processing continues to serve your production workload.

    To monitor the progress of the SOFTFAIL:

    • Verify that the node(s) you specified are indeed marked for removal.

      SELECT * FROM system.softfailed_nodes;
      
    • The system.softfailing_containers tables will show the list of containers that are slated to be moved as part of the SOFTFAIL operation. When this query returns 0 rows, the data migration is complete.

      SELECT * FROM system.softfailing_containers;
      
    • This query shows the list of softfailed node(s) that are ready for removal:

      SELECT * FROM system.softfailed_nodes
      WHERE instance_id NOT IN
         (SELECT DISTINCT instance_id
         FROM system.softfailing_containers);
      

    Once the SOFTFAIL is complete for all nodes, the clustrix.log file will contain the following message:

    softfailing nodes are ready to be removed: <list of instance_ids>
    
  3. Remove soft failed nodes(s) from your deployment

    To remove the softfailed node(s) from the deployment, issue the following SQL command:

    ALTER CLUSTER REFORM;
    

    There will be a brief interruption of service while the node(s) are removed.