DEV Community

Michael
Michael

Posted on • Originally published at gbase8.cn

Managing the FoundationDB Cluster in GCDW: Start/Stop, Scale, Replace, and Upgrade

FoundationDB serves as the metadata backbone for GCDW (GBase Cloud Data Warehouse). Keeping it healthy is essential for the entire gbase database platform. This guide covers the core operational tasks — service control, cluster file handling, node expansion, safe removal, hardware replacement, and version upgrades — using a 3‑node FDB cluster as the example.

Service Lifecycle and Auto‑Start

FoundationDB uses fdbmonitor to supervise fdbserver and backup_agent, while systemd supervises fdbmonitor. All commands must be run on each node individually.

# Start
systemctl start foundationdb

# Stop
systemctl stop foundationdb

# Check status (Active: active (running) indicates normal)
systemctl status foundationdb

# Disable auto‑start on boot
systemctl disable foundationdb

# Enable auto‑start on boot
systemctl enable foundationdb
Enter fullscreen mode Exit fullscreen mode

Cluster File Management

The cluster connection string is stored in /etc/foundationdb/fdb.cluster and is identical on every node. Its format is description:ID@IP:PORT,IP:PORT,....

  • Specify a custom cluster file for clients: fdbcli -C /path/to/fdb.cluster
  • In APIs: Python's fdb.open(cluster_file=...) or Java's FDB.open(path) accept a custom path.
  • Environment variable: Set FDB_CLUSTER_FILE (lower priority than the ‑C flag, higher than the default location).
  • Retrieve current cluster info from a connected session:
  fdb> get \xFF\xFF/cluster_file_path    # file path
  fdb> get \xFF\xFF/connection_string    # connection string
Enter fullscreen mode Exit fullscreen mode

Expanding the Cluster: Adding Nodes

  1. Install the FoundationDB packages on the new node.
  2. Copy the existing /etc/foundationdb/fdb.cluster to the same path on the new node.
  3. Restart the FDB service:
   systemctl restart foundationdb
Enter fullscreen mode Exit fullscreen mode

The new node will automatically join and start serving data.

Shrinking the Cluster: Removing Nodes

  1. Verify redundancy: Ensure the remaining nodes still meet the redundancy mode (e.g., double requires at least 2 machines).
  2. Reconfigure coordinators (if the node being removed is a coordinator):
   fdb> coordinators 10.0.2.81:4500 10.0.2.82:4500
Enter fullscreen mode Exit fullscreen mode
  1. Exclude the node to trigger data migration:
   fdb> exclude 10.0.2.83:4500
Enter fullscreen mode Exit fullscreen mode
  • This operation can take a while. Pressing Ctrl+C only stops the progress display; the data movement continues in the background.
  • Run fdb> exclude to see the current exclusion list.
    1. Stop and remove the service:
   systemctl stop foundationdb
   systemctl disable foundationdb
   yum remove foundationdb-server foundationdb-client
Enter fullscreen mode Exit fullscreen mode
  1. Rollback: To cancel an exclusion, run fdb> include all.

Replacing a Machine

A replacement is simply a combination of expansion and shrinkage: add the new node, wait for data rebalancing, then exclude and remove the old node.

Uninstallation and Upgrades

  • Uninstall: Remove the RPM packages directly.
  rpm -e foundationdb-clients foundationdb-server
Enter fullscreen mode Exit fullscreen mode
  • Upgrade: Run the RPM upgrade on every node. All nodes must be upgraded to the same version.
  rpm -Uvh foundationdb-clients-7.2.3-1.el7.x86_64.rpm foundationdb-server-7.2.3-1.el7.x86_64.rpm
Enter fullscreen mode Exit fullscreen mode

Key Takeaways

Mastering FoundationDB's start/stop, cluster file, and scaling procedures is essential for maintaining the high availability of your GCDW metadata layer. Always verify fdb.cluster permissions, and double‑check your redundancy policy before changing coordinators or running exclude. With these practices, your gbase database infrastructure will remain solid and predictable.

Top comments (0)