1. Home
  2. Docs
  3. ClusterControl
  4. Troubleshooting
  5. Known Limitations

Known Limitations

ClusterControl is a complex and sophisticated product. It consists of several components and it is recommended to run it on a dedicated host. Here are some noteworthy and known limitations that we have gathered so far:

General

  • ClusterControl can not reside on the same host as the database nodes that you want to deploy or import. ClusterControl must be running on an independent node away from your database clusters/servers.
  • For good long-term support, do not co-locate ClusterControl with other applications outside of ClusterControl’s control. For example, do not co-locate ClusterControl with a DNS server, an email server, or on a hosting server controlled by a control panel manager. A dedicated host is recommended.
  • Not all functionalities are available on both user interfaces, ClusterControl GUI and ClusterControl CLI. The command-line client is focused on automation and adoption in management, deployment and scaling operations while the web UI client, focuses more on structural visualization with a guided approach.
  • In terms of Linux security, ClusterControl does not manage firewalls (iptables, ufw, firewalld) or any Linux kernel security modules like SELinux or AppArmor. ClusterControl only offers a switch for this feature to be turned on or off while deployment to reduce the risk of deployment errors. The SysAdmin is responsible for these aspects.

SSH

  • ClusterControl requires the SSH user to be a sudo user without restrictions or simply a root user.
  • ClusterControl only supports OpenSSH. Other SSH implementations like Dropbear and TinySSH are not supported.

MySQL/MariaDB

  • ClusterControl does not support managing multiple MySQL and MariaDB instances running on a single host. This includes multiple MySQL/MariaDB instances running on Docker container or running MySQL/MariaDB instances via mysqld_multi, MySQL Sandbox or DBdployer.
  • ClusterControl only supports GTID-based replication (both MySQL’s and MariaDB’s) for automatic failover and recovery. If you are running on a position-based replication, ClusterControl is still able to manage and monitor it without supporting the automatic failover.
  • When importing an existing MySQL/MariaDB server/cluster into ClusterControl, some non-destructive configurations will be appended:
    • CMON database user.
    • Backup database user credentials.
    • Some systemd configuration for MySQL/MariaDB will be overridden e.g, Galera Cluster to allow long SST.
    • Read-only flag (MySQL/MariaDB replication).
  • When automatic recovery is enabled, ClusterControl always tries to be as conservative as possible when recovering a cluster or a database node. For example, it will always start/restart node one node at a time (not multiple at once), it will always force one master at a time (MySQL replication) or in case of network flapping, ClusterControl will attempt to recover the cluster once and if it keeps failing instantaneously, it will back off on the second attempt and raise an alarm. ClusterControl provides many hooks for you to extend the recovery and failover behavior, as shown on the Configuration Options.

Containerization

  • Although Severalnines offers ClusterCluster as a Docker image, it is not intended for production usage. ClusterControl product direction is never intended to run on a container environment due to its internal logic and system design. We are maintaining the Docker image on a best-effort basis, and it is not part of the product development projection and pipeline.
  • Supporting on database instances running on the Docker container is fairly limited. ClusterControl requires an SSH server to communicate and control the instance, which commonly does not come with the database’s Docker image (which defeats the purpose of microservices). You either have to install an SSH server on the container or use a special image that comes with SSH like centos-ssh.

Monitoring

  • When agent-based monitoring is activated, ClusterControl will control the Prometheus and all exporters’ processes to avoid false positives when observing the node and cluster state. Hence, ClusterControl does not support importing an existing Prometheus configured and deployed outside of ClusterControl.
Was this article helpful to you? Yes No