Codership, the leading MySQL High Availability clustering solutions company behind Galera Cluster
, is pleased to announce the general availability
of Galera Manager
, a web-based graphical user interface (GUI) tool to easily deploy and manage your Galera Clusters. With today’s release, you can now create fully managed clusters in Amazon Web Services, you can also deploy clusters on user provided hosts (on premise or in the cloud) and you can also fully monitor your existing clusters.
We now have the concept of a managed node (your typical MySQL instance) and managed host (your typical Linux instance) which you use to deploy Galera Cluster in Amazon EC2, a managed node and a monitored host for user provided hosts (on premise or in the cloud) and just a monitored node and host for existing Galera Clusters that you would like be monitored, in the new and improved cluster deployment wizard. We can monitor over 600 metrics either cluster-wide or on a node basis. We have expanded support to include various Linux distributions and also more MySQL and MariaDB Server instances. We support CentOS 7, CentOS 8, Red Hat Enterprise Linux 8, Debian 10, Ubuntu 18.04 and Ubuntu 20.04, while we support MariaDB 10.3, MariaDB 10.4 and MariaDB 10.5 as well as MySQL 5.7 and MySQL 8.0.
When you choose to use a fully managed cluster within Amazon Web Services (AWS), Galera Manager now configures the firewall for you via Security Groups. This ensures that Galera Manager has access to the nodes, and that there is constant communication between the nodes, and you can also then SSH (port 22) as well as connect to MySQL remotely (ports 3306 and 33060). Port 33060 is open for the MySQL X Protocol, which is required now for our new CLONE SST method available in MySQL 8.
Now we also fetch available regions and EC2 instance types from AWS, so we do caution you to ensure you pick an x86_64 instance type, not an ARM64 instance type (for a successful deployment, Galera Manager and Galera Cluster currently runs on x86_64 only, not ARM). A tip would be to type “t” to get to a small t2 instance type for testing.
We’ve made some small improvements like validating the AWS Access Key ID and Secret Access Key while you’re creating the cluster or adding a node, and this visual confirmation confirms that there will be less chances of failure in creating a node.
Another point to note is that you may have to also accept the EULA’s for your instances from Amazon, so if your cluster deployment fails for any reason, please check the logs. The following are two common errors within the logs that require some kind of manual intervention:
deployment status error: failed to run EC2 instance: attempt count exceeded: InvalidParameterValue: The architecture ‘arm64’ of the specified instance type does not match the architecture ‘x86_64’ of the specified AMI. Specify an instance type and an AMI that have matching architectures, and try again. You can use ‘describe-instance-types’ or ‘describe-images’ to discover the architecture of the instance type or AMI. status code: 400, request id: 6e508fd8-2dff-46e5-944c-c67d2461d2d1
The fix for the above is to ensure you are using an x86_64 instance type and not an ARM AMI.
deployment status error: failed to run EC2 instance: attempt count exceeded: OptInRequired: In order to use this AWS Marketplace product you need to accept terms and subscribe. To do so please visit https://aws.amazon.com/marketplace/pp?sku=a8jyynf4hjutohctm41o2z18m status code: 401, request id: 634d23f7-2e7d-47d9-b977-e0d03cb5044f
The fix for the above is to ensure that you copy and paste the URL from the logs, and agree to the EULA, and the appropriate billing for the instance type (e.g. if you use Red Hat Enterprise Linux 8).
We still have documentation
at the same location, and we have also opened up a GitHub repository for support issues
. Please download Galera Manager
and we look forward to your feedback.