codership / galera-manager-support Goto Github PK

After adding a existing CentOS host I found this potential error in filebeat.yml:

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - ABORT_SERVER^M
stderr^M
3^M

    - /var/lib/mysql/node1.log^M

    - /var/lib/mysql/node1-slow.log^M

Somehow that doesn't look right to me and filebeat complains during startup.

I kept getting ssh auth error like below:

Sep 17, 2021 12:03:31 | galera-manager | deployment status ok
Sep 17, 2021 12:03:34 | galera-manager | [email protected]# cat /etc/galera-manager-node
Sep 17, 2021 12:03:34 | host-stdout | {"host":{"id":"1","name":"galnode1","type":"unmanaged","system":"centos:7","privateKey":"-----BEGIN RSA PRIVATE KEY-----[private]\n-----END RSA PRIVATE KEY-----","authorizedKeys":["ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDcF3nSw5Od+SnKaGLXeJzC1HR2p4RP9VA6mGgBqgp04WmHfA0khIO2ET/8o1v7vNHrLRgAJxXZHm4jzwDCuAFWIbYMVq3lZR3WNy2tXDvYWA08wXKhanWM0CHnvOmwsEQs/wk7/9CyzrCKsosR/HWQEvjeCubU4C5n3RSWFvszWGJxydvWalAOOIL4rdUuUeO8SkILYY5AGv0lxNtvE24umpf3O6OKAMRxmC2MMoAfAiXNtIawR/VwmNfPpiizub1XLqDMyQzhK5jI63jeXuupRjGith8Ly6N+uxK/tmJNSnNsrARj/asLDjd0GooTVaXqxHG6LYadeklOLVYNkUjz root@galnode1\n","ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDcF3nSw5Od+SnKaGLXeJzC1HR2p4RP9VA6mGgBqgp04WmHfA0khIO2ET/8o1v7vNHrLRgAJxXZHm4jzwDCuAFWIbYMVq3lZR3WNy2tXDvYWA08wXKhanWM0CHnvOmwsEQs/wk7/9CyzrCKsosR/HWQEvjeCubU4C5n3RSWFvszWGJxydvWalAOOIL4rdUuUeO8SkILYY5AGv0lxNtvE24umpf3O6OKAMRxmC2MMoAfAiXNtIawR/VwmNfPpiizub1XLqDMyQzhK5jI63jeXuupRjGith8Ly6N+uxK/tmJNSnNsrARj/asLDjd0GooTVaXqxHG6LYadeklOLVYNkUjz\n"],"hostTypeSpecific":{"enableFirewall":false},"segment":0,"clusterID":"1","ssh":{"address":"192.168.254.53","port":"22"},"db":{"address":"192.168.254.53","port":"3306"},"deploymentStatus":"ok","createdBy":"","createdAt":"2021-09-15T12:14:02.054180951+09:00"},"node":{"id":"1","name":"galnode1","clusterID":"1","dbEngine":"mariadb:10.4","userConfig":"","settings":{"logs":{"generalLog":{"path":"/var/log/mysql/general.log","enabled":false},"slowLog":{"path":"/var/log/mysql/mysql-slow.log","enabled":false},"errorLog":{"path":"/var/log/mysql/error.log","enabled":false}}},"deploymentStatus":"error","unmanaged":true,"createdBy":"","createdAt":"2021-09-15T12:14:04.997023216+09:00","cert":"[skipped]"}}
Sep 17, 2021 12:03:34 | galera-manager | the selected host already has a node installed: {"host":{"id":"1","name":"galnode1","type":"unmanaged","system":"centos:7","privateKey":"-----BEGIN RSA PRIVATE KEY-----[skipped]\n-----END RSA PRIVATE KEY-----","authorizedKeys":["ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDcF3nSw5Od+SnKaGLXeJzC1HR2p4RP9VA6mGgBqgp04WmHfA0khIO2ET/8o1v7vNHrLRgAJxXZHm4jzwDCuAFWIbYMVq3lZR3WNy2tXDvYWA08wXKhanWM0CHnvOmwsEQs/wk7/9CyzrCKsosR/HWQEvjeCubU4C5n3RSWFvszWGJxydvWalAOOIL4rdUuUeO8SkILYY5AGv0lxNtvE24umpf3O6OKAMRxmC2MMoAfAiXNtIawR/VwmNfPpiizub1XLqDMyQzhK5jI63jeXuupRjGith8Ly6N+uxK/tmJNSnNsrARj/asLDjd0GooTVaXqxHG6LYadeklOLVYNkUjz root@galnode1\n","ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDcF3nSw5Od+SnKaGLXeJzC1HR2p4RP9VA6mGgBqgp04WmHfA0khIO2ET/8o1v7vNHrLRgAJxXZHm4jzwDCuAFWIbYMVq3lZR3WNy2tXDvYWA08wXKhanWM0CHnvOmwsEQs/wk7/9CyzrCKsosR/HWQEvjeCubU4C5n3RSWFvszWGJxydvWalAOOIL4rdUuUeO8SkILYY5AGv0lxNtvE24umpf3O6OKAMRxmC2MMoAfAiXNtIawR/VwmNfPpiizub1XLqDMyQzhK5jI63jeXuupRjGith8Ly6N+uxK/tmJNSnNsrARj/asLDjd0GooTVaXqxHG6LYadeklOLVYNkUjz\n"],"hostTypeSpecific":{"enableFirewall":false},"segment":0,"clusterID":"1","ssh":{"address":"192.168.254.53","port":"22"},"db":{"address":"192.168.254.53","port":"3306"},"deploymentStatus":"ok","createdBy":"","createdAt":"2021-09-15T12:14:02.054180951+09:00"},"node":{"id":"1","name":"galnode1","clusterID":"1","dbEngine":"mariadb:10.4","userConfig":"","settings":{"logs":{"generalLog":{"path":"/var/log/mysql/general.log","enabled":false},"slowLog":{"path":"/var/log/mysql/mysql-slow.log","enabled":false},"errorLog":{"path":"/var/log/mysql/error.log","enabled":false}}},"deploymentStatus":"error","unmanaged":true,"createdBy":"","createdAt":"2021-09-15T12:14:04.997023216+09:00","cert":"[skipped]"}}
Sep 17, 2021 12:03:34 | galera-manager | Saving Galera Manager node data
Sep 17, 2021 12:03:34 | galera-manager | Writing to /etc/galera-manager-node
Sep 17, 2021 12:05:05 | galera-manager | [email protected]# cat /etc/galera-manager-node
Sep 17, 2021 12:05:05 | host-stdout | {"host":{"id":"1","name":"galnode1","type":"unmanaged","system":"centos:7","privateKey":"-----BEGIN RSA PRIVATE KEY-----[skipped]\n-----END RSA PRIVATE KEY-----","authorizedKeys":["ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDhnx7bCvKknrdYZGC4qxKdpmsst13iIU/UL/2c+x5MyrMjm4bfwnSYWdA4jT0ZO67O71NDquyeBfT15Fl2zqGKr13oUF1ZtdJLfcUStXSHD+WEGKh4WNFh8cJSly+sTpIJyaa1Pw0i6DhBo1WwKBjpB9qNF9NqJdUDvUgZdJ9LcU8ZwO19+18OVz7Jei2iQKlFLY07qscH2G75rb8Vx1LLlIzcaGuA+BTS4p6N7sOF73xzeDhuWOJWWz0mgjclgu3mdEe/3SBVn2kzTdf87kBQmLfWhQpBoq54Az/JTkiH4DP4O8v3e9/wvkIhORnY2ydbZy11sJOQzsk35XmufdHN root@galeramanager","ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDhnx7bCvKknrdYZGC4qxKdpmsst13iIU/UL/2c+x5MyrMjm4bfwnSYWdA4jT0ZO67O71NDquyeBfT15Fl2zqGKr13oUF1ZtdJLfcUStXSHD+WEGKh4WNFh8cJSly+sTpIJyaa1Pw0i6DhBo1WwKBjpB9qNF9NqJdUDvUgZdJ9LcU8ZwO19+18OVz7Jei2iQKlFLY07qscH2G75rb8Vx1LLlIzcaGuA+BTS4p6N7sOF73xzeDhuWOJWWz0mgjclgu3mdEe/3SBVn2kzTdf87kBQmLfWhQpBoq54Az/JTkiH4DP4O8v3e9/wvkIhORnY2ydbZy11sJOQzsk35XmufdHN\n"],"hostTypeSpecific":{"enableFirewall":false},"segment":0,"clusterID":"3","ssh":{"address":"192.168.254.53","port":"22"},"db":{"address":"192.168.254.53","port":"3306"},"deploymentStatus":"ok","createdBy":"","createdAt":"2021-09-17T12:03:31.475460919+09:00"},"node":{"id":"1","name":"galnode1","clusterID":"3","dbEngine":"mariadb:10.4","userConfig":"","settings":{"logs":{"generalLog":{"path":"/var/log/mysql/general.log","enabled":false},"slowLog":{"path":"/var/log/mysql/mysql-slow.log","enabled":false},"errorLog":{"path":"/var/log/mysql/error.log","enabled":false}}},"deploymentStatus":"error","unmanaged":true,"createdBy":"","createdAt":"2021-09-17T12:03:34.637906481+09:00","cert":"[skipped]"}}
Sep 17, 2021 12:05:12 | galera-manager | starting node
Sep 17, 2021 12:05:12 | galera-manager | checking installation
Sep 17, 2021 12:05:12 | galera-manager | [email protected]# cat /etc/galera-manager-node
Sep 17, 2021 12:05:12 | host-stdout | {"host":{"id":"1","name":"galnode1","type":"unmanaged","system":"centos:7","privateKey":"-----BEGIN RSA PRIVATE KEY-----[skipped]\n-----END RSA PRIVATE KEY-----","authorizedKeys":["ssh-rsa [skipped] root@galeramanager","ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDhnx7bCvKknrdYZGC4qxKdpmsst13iIU/UL/2c+x5MyrMjm4bfwnSYWdA4jT0ZO67O71NDquyeBfT15Fl2zqGKr13oUF1ZtdJLfcUStXSHD+WEGKh4WNFh8cJSly+sTpIJyaa1Pw0i6DhBo1WwKBjpB9qNF9NqJdUDvUgZdJ9LcU8ZwO19+18OVz7Jei2iQKlFLY07qscH2G75rb8Vx1LLlIzcaGuA+BTS4p6N7sOF73xzeDhuWOJWWz0mgjclgu3mdEe/3SBVn2kzTdf87kBQmLfWhQpBoq54Az/JTkiH4DP4O8v3e9/wvkIhORnY2ydbZy11sJOQzsk35XmufdHN\n"],"hostTypeSpecific":{"enableFirewall":false},"segment":0,"clusterID":"3","ssh":{"address":"192.168.254.53","port":"22"},"db":{"address":"192.168.254.53","port":"3306"},"deploymentStatus":"ok","createdBy":"","createdAt":"2021-09-17T12:03:31.475460919+09:00"},"node":{"id":"1","name":"galnode1","clusterID":"3","dbEngine":"mariadb:10.4","userConfig":"","settings":{"logs":{"generalLog":{"path":"/var/log/mysql/general.log","enabled":false},"slowLog":{"path":"/var/log/mysql/mysql-slow.log","enabled":false},"errorLog":{"path":"/var/log/mysql/error.log","enabled":false}}},"deploymentStatus":"error","unmanaged":true,"createdBy":"","createdAt":"2021-09-17T12:03:34.637906481+09:00","cert":"[skipped]"}}
Sep 17, 2021 12:05:12 | galera-manager | unmanaged node cannot be started github.com/codership/galera-manager/pkg/internal/mgmt/units.(*Node).Start /go/pkg/internal/mgmt/units/node.go:378 github.com/codership/galera-manager/pkg/internal/mgmt.(*Nodes).Start.func1 /go/pkg/internal/mgmt/nodes.go:174 github.com/codership/galera-manager/pkg/internal/jobs.(*Processor).Execute.func1 /go/pkg/internal/jobs/processor.go:73 runtime.goexit /usr/local/go/src/runtime/asm_amd64.s:1371
Sep 17, 2021 12:05:12 | galera-manager | Unexpected error. Check the server logs.: unmanaged node cannot be started
Sep 17, 2021 12:05:12 | galera-manager | error starting the node: unmanaged node cannot be started github.com/codership/galera-manager/pkg/internal/mgmt/units.(*Node).Start /go/pkg/internal/mgmt/units/node.go:378 github.com/codership/galera-manager/pkg/internal/mgmt.(*Nodes).Start.func1 /go/pkg/internal/mgmt/nodes.go:174 github.com/codership/galera-manager/pkg/internal/jobs.(*Processor).Execute.func1 /go/pkg/internal/jobs/processor.go:73 runtime.goexit /usr/local/go/src/runtime/asm_amd64.s:1371 Unexpected error. Check the server logs. github.com/codership/galera-manager/pkg/internal/mgmt/units.(*Node).Start.func1 /go/pkg/internal/mgmt/units/node.go:365 github.com/codership/galera-manager/pkg/internal/mgmt/units.(*Node).Start /go/pkg/internal/mgmt/units/node.go:378 github.com/codership/galera-manager/pkg/internal/mgmt.(*Nodes).Start.func1 /go/pkg/internal/mgmt/nodes.go:174 github.com/codership/galera-manager/pkg/internal/jobs.(*Processor).Execute.func1 /go/pkg/internal/jobs/processor.go:73 runtime.goexit /usr/local/go/src/runtime/asm_amd64.s:1371

what is the best way to add private key and authorized key to galara manager?
Here is my step

• ssh-keygen on galara maanage node
• run "ssh-copy-id -i ~/.ssh/id_rsa.pub " for 3 galera nodes
• cat ~/.ssh/id_rsa from galera manager node and copy it then added to galera manager Web UI when creating cluster
• cat ~/.ssh/authorized_keys from one of galera node and then copy it t then added to galera manager Web UI when creating cluster

At this point, I can root access to every galera node from galera manger node.

However, whenever I add node to galera manager, node is added, but error shows like above on deployment log.

Any thought?

When trying to add a Node the SSH check fails with:

failed to execute info script:
failed to load executor:
invalid command type:
"ssh_exec"

In /var/log/secure

Nov  7 18:16:26 dbmariadbpoc01 sshd[1638033]: Accepted publickey for root from [redacted] port 60102 ssh2: RSA SHA256:[redacted]
Nov  7 18:16:26 dbmariadbpoc01 sshd[1638033]: pam_unix(sshd:session): session opened for user root by (uid=0)
Nov  7 18:16:26 dbmariadbpoc01 sshd[1638033]: pam_unix(sshd:session): session closed for user root
Nov  7 18:16:26 dbmariadbpoc01 sshd[1638059]: Accepted publickey for root from [redacted] port 60104 ssh2: RSA SHA256:[redacted]

Can you help me ?

Would be good to deploy in kubernetes!
(Yes, dependency is that Galera itself needs k8s support)

When you deploy a new cluster with user provided hosts, the "Custom DB engine configuration" is not available.
As the DB engine installation in the node is managed by Galera Manager, there is no easy option to modify its configuration.

• clean installed latest gmc version 1.5.0 on deb 11
• launch web interface
• add node - select a clean install deb 11 server with mariadb on it
• check access all ok
• press install and then the interface shows login screen
• log back in and node is in stray hosts - pending. Never gets added.
• delete this node - on pressing the confirmation button again throws you back to the login screen. Node is not deleted.
• force delete works ok

I have problem installing galera mamanger on Ubuntu bionic.
When execute installer I have this error:
ERRO[0043] command failed (stepName=install_curl, commandId=8, commandType=ExecCommand): exit status 100

When run "apt-get update" this is the error:
Err:4 https://repo.galera-manager.com/nexus/repository/galera-manager-release-1804 bionic Release
Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 134.209.245.63 443]

Please help me.

Hello from DigitalOcean 👋

I'm on the API Engineering team, and we recently updated our API token formats. It appears this is causing issues with Galera's recently released DigitalOcean support.

When trying to create a new cluster with a new token format, I see the following error:

{
  "errors": [
    {
      "code": "validation_match_invalid",
      "title": "Validation Error",
      "detail": "must be in a valid format",
      "source": {
        "pointer": "/data/attributes/sharedConfig/host/hostTypeSpecific/accessToken"
      }
    }
  ]
}

Given the value of the pointer field, it makes me think that the issue is with the validation of the new tokens.

Our new tokens can be checked using the regex /do[opr]_v\d_[0-9a-f]{64}/g. An example of a valid new API token is dop_v1_abc1230000000000000000000000000000000000000000000000000000000000. For now, users can have both our older tokens (which were random 64 character hexadecimal strings), or the new format, so both should be supported to resolve this issue.

If there's anything I can do to help, or if you need any more information, please let me know. Thanks!

I've deployed this successfully in our staging environment but was starting to install it in our production environment and I've run into the following problem. Running 1.5.0.

When I add a monitored cluster the UI hangs/spins on CREATING. I've been patient (10+ minutes) and if I refresh the page the cluster appears listed but has a Running Job of "cluster deploy". If I try to deploy a node from it the "Check Access" button will hang in the same way.

I've tried to force delete and recreate a new cluster. I've uninstalled and reinstalled Galera Manager via apt-get purge. I'm currently running Ubuntu 20.04 with a 10.3.31 Galera cluster. I don't see any output in terms of logs at /var/log/gmd. The Logs UI shows "Log is empty"

Any suggestions? Thanks in advance.

There is no option to have a 2-node galera cluster with 1 garbd node. Garbd is completely missing from the process, and sometimes people want to run a 2-node cluster with powerful hardware, and one garbd node with a small instance.

let the user run apache2 on port 80 and let Galera Manager work instead of nginx

in parallel, let Galera Manager be installed on a machine that also has existing software

(seems that the installer didn't check to see if port 80 was already being used by something else, thus maybe causing a silent failure)

see: https://groups.google.com/g/codership-team/c/mx72_yG-_9s/m/85ei-rNhAwAJ?utm_medium=email&utm_source=footer

I have a galera 4 cluster with two MySQL 8 nodes and garbd. I would like to test the new streaming replication feature but can't enable it.
I do not use MariaDB which is found in most of the documentation for this feature. Isn't it available for MySQL 8?

wsrep_provider -> /usr/lib64/galera-4/libgalera_smm.so
mysql -> 8.0.25 MySQL Community Server

SET SESSION wsrep_trx_fragment_size=1;
ERROR 1231 (42000): Variable 'wsrep_trx_fragment_size' can't be set to the value of '1'
SET SESSION wsrep_trx_fragment_size=0;
Query OK, 0 rows affected (0,01 sec)

Hello,

I have a cluster managed by galera manager 1.7.3 and influxdb 2.5.1,
manager and nodes are Debian 10 systems and using MariaDB 10.6.
One of the nodes are most of the time in grey without status, the transactions are increasing in all nodes and all are synced.
The cluster has 3 member and only node 3 appears in grey, the node is actually synced but galera manager doesn´t know.

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| wsrep_cluster_status | Primary |
+----------------------+---------+
1 row in set (0,002 sec)

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------+
| Variable_name             | Value  |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+
1 row in set (0,002 sec)

Is there any bug regarding this?

Best Regards

I attempted to install gm-installer on Ubuntu 22.04 but received the error "unsupported os" which makes sense because Jammy came out earlier this year. What are the plans for adding 22.04 to both the manager and nodes?

gm-installer cannot bind to port 80. Installing servers with no access to internet.

This is a fresh install of RHEL 8, no apache, no nginx, no firewalld, selinux set to permissive, nothing listening on any port except SSH.

[myacct ~]$ sudo netstat -an | grep -w LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
[myacct ~]$ getenforce
Permissive
[myacct ~]$ ./gm-installer version
gm-installer version 1.6.0 (linux/amd64)
[myacct ~]$ uname -a
Linux mygm.ad.local 4.18.0-348.2.1.el8_5.x86_64 #1 SMP Mon Nov 8 13:30:15 EST 2021 x86_64 x86_64 x86_64 GNU/Linux
[myacct ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux release 8.5 (Ootpa)

...
Since you entered an IP address, SSL won't be available.
The installation log is located at /tmp/gm-installer.log
ERRO[0047] Cannot bind to 0.0.0.0:80; this address is used by a web server, make sure it's not used and re-run the installer.

[myacct ~]$ ls -l /tmp/gm-installer.log
-rw-------. 1 root root 0 Jan 11 12:01 /tmp/gm-installer.log

empty log

The latest changes to gmd work really well on DigitalOcean. Thanks!

I cannot seem to find documentation about how to tell the cluster that it should communicate between the nodes using the internal (VPC) IP addresses of the various hosts instead of their public IP addresses.

Also, it would be great if there were a way to define a DigitalOcean droplet tag (or tags) for any new droplets created, since that would be a good way to enforce firewall rules and policies. Is there a possibility of this?

GMD-Version: Galera-Manager 1.7.2
OS: Debian GNU/Linux 11 (bullseye)

When trying to add a Node to user-provided or monitor existing cluster, the SSH check fails with:

failed to execute info script:
failed to load executor:
invalid command type:
"box_include"

Exception:

{
  "channel-type": "app",
  "file": "/go/pkg/internal/sshcmd/host.go:254",
  "func": "github.com/codership/galera-manager/pkg/internal/sshcmd.(*Host).RunConn",
  "host-name": "galera-1",
  "level": "info",
  "msg": "root@galera-1# echo -n \"test\"",
  "time": "2022-09-27T11:48:58+02:00"
} {
  "channel-type": "stdout",
  "file": "/go/pkg/log/iolog.go:37",
  "func": "github.com/codership/galera-manager/pkg/log.(*IOLog).Write",
  "host-name": "galera-1",
  "level": "info",
  "msg": "test",
  "time": "2022-09-27T11:48:58+02:00"
} {
  "channel-type": "app",
  "error": {
    "msg": "failed to execute info script",
    "stackTrace": [
      "github.com/codership/galera-manager/pkg/internal/mgmt.(*Checker).CheckServerAccess.func1\n\t/go/pkg/internal/mgmt/checker.go:127",
      "github.com/codership/galera-manager/pkg/internal/jobs.(*Processor).Execute.func1\n\t/go/pkg/internal/jobs/processor.go:90",
      "runtime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1594"
    ],
    "wrapped": {
      "msg": "failed to load executor",
      "stackTrace": [
        "github.com/codership/galera-manager/pkg/internal/sshcmd.(*Host).RunScriptWithConnNoDB\n\t/go/pkg/internal/sshcmd/executor.go:150",
        "github.com/codership/galera-manager/pkg/internal/mgmt.(*Checker).CheckServerAccess.func1\n\t/go/pkg/internal/mgmt/checker.go:118",
        "github.com/codership/galera-manager/pkg/internal/jobs.(*Processor).Execute.func1\n\t/go/pkg/internal/jobs/processor.go:90",
        "runtime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1594"
      ],
      "wrapped": {
        "msg": "invalid command type: \"box_include\"",
        "stackTrace": [
          "gitlab.galeracluster.com/lib/executor.(*Executor).AppendScenario\n\t/go/.go/pkg/mod/gitlab.galeracluster.com/lib/[email protected]/executor.go:318",
          "gitlab.galeracluster.com/lib/executor.NewWithScenario\n\t/go/.go/pkg/mod/gitlab.galeracluster.com/lib/[email protected]/executor.go:181",
          "github.com/codership/galera-manager/pkg/internal/sshcmd.(*Host).RunScriptWithConnNoDB\n\t/go/pkg/internal/sshcmd/executor.go:138",
          "github.com/codership/galera-manager/pkg/internal/mgmt.(*Checker).CheckServerAccess.func1\n\t/go/pkg/internal/mgmt/checker.go:118",
          "github.com/codership/galera-manager/pkg/internal/jobs.(*Processor).Execute.func1\n\t/go/pkg/internal/jobs/processor.go:90",
          "runtime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1594"
        ]
      }
    },
    "fields": {
      "db_engine": "",
      "system": "debian:11"
    }
  },
  "file": "/go/pkg/internal/mgmt/checker.go:133",
  "func": "github.com/codership/galera-manager/pkg/internal/mgmt.(*Checker).CheckServerAccess.func1",
  "host-name": "galera-1",
  "level": "error",
  "msg": "failed to execute info script",
  "time": "2022-09-27T11:48:58+02:00"
} {
  "channel-type": "app",
  "file": "/go/pkg/internal/sshcmd/host.go:254",
  "func": "github.com/codership/galera-manager/pkg/internal/sshcmd.(*Host).RunConn",
  "host-name": "galera-1",
  "level": "info",
  "msg": "root@galera-1# echo -n \"test\"",
  "time": "2022-09-27T11:49:52+02:00"
} {
  "channel-type": "stdout",
  "file": "/go/pkg/log/iolog.go:37",
  "func": "github.com/codership/galera-manager/pkg/log.(*IOLog).Write",
  "host-name": "galera-1",
  "level": "info",
  "msg": "test",
  "time": "2022-09-27T11:49:52+02:00"
}

From the logs:
Sep 27, 2022 11:49:53 | info | root@galera-1# echo -n "test"
Sep 27, 2022 11:49:53 | info | test
Sep 27, 2022 11:49:53 | error | failed to execute info script

Hello,

GMD: v1.3.0
GUI: v1.3.0

The node deployment fails with the error No package galera-manager-filebeat available.

Sep 06, 2021 12:12:54 | host-stdout | (1/6): extras/7/x8 | 243 kB 00:00
Sep 06, 2021 12:12:54 | host-stdout | (2/6): updates/7/x | 10 MB 00:00
Sep 06, 2021 12:12:54 | host-stdout |
Sep 06, 2021 12:12:54 | host-stdout | (3/6): epel/x86_64 | 7.0 MB 00:00 (5/6): galera- 94% | 18 MB --:-- ETA (4/6): influxdb/pr | 57 kB 00:00
Sep 06, 2021 12:12:54 | host-stdout | (5/6): epel/x86_64 | 1.0 MB 00:00
Sep 06, 2021 12:12:54 | host-stdout | (6/6): galera-mana | 2.2 kB 00:00
Sep 06, 2021 12:12:58 | host-stdout | galera-manager: [# ] 1/12 galera-manager: [## ] 2/12 galera-manager: [#### ] 3/12 galera-manager: [##### ] 4/12 galera-manager: [###### ] 5/12 galera-manager: [######## ] 6/12 galera-manager: [######### ] 7/12 galera-manager: [########## ] 8/12 galera-manager: [############ ] 9/12 galera-manager: [############ ] 10/12 galera-manager: [############# ] 11/12 galera-manager 12/12
Sep 06, 2021 12:13:15 | host-stdout | No package �[1mgalera-manager-filebeat�(B�[m available.
Sep 06, 2021 12:13:16 | host-stdout | Error: Nothing to do
Sep 06, 2021 12:13:16 | galera-manager | Got an error and attepts = 0
Sep 06, 2021 12:13:16 | galera-manager | failed to execute cluster config script (RunScriptWithConn): command failed (stepName=install_filebeat, commandId=8, commandType=ExecCommand): Process exited with status 1
Sep 06, 2021 12:13:16 | galera-manager | Saving Galera Manager node data
Sep 06, 2021 12:13:16 | galera-manager | Writing to /etc/galera-manager-node

I noticed something that could be related to the problem ? Here is the content of the /etc/yum.repos.d/galera-manager.repo file.

[galera-manager]
name = Galera Manager
baseurl = https://repo.galera-manager.com/nexus/repository/galera-manager-release
gpgcheck = 0

But https://repo.galera-manager.com/nexus/repository/galera-manager-release redirects to a 404 not found page.

Created a new debian 11 VM.
Downloaded latest gm-installer
root@xx:~# ./gm-installer version
gm-installer version 1.6.0 (linux/amd64)

At the end of run says:

ERRO[0019] unsupported os

Article
https://galeracluster.com/2022/02/galera-manager-february-2022-release/

Says this version is the latest Feb release and that Debian 11 is supported

I've tried creating nodes on M5 and R5 instances and the install script gets an error about not being able to find the block device for the hard drive when making an xfs

Error accessing specified device /dev/xvdh: No such file or directory

It works for T2 instances

Greetings

I've set up my first cluster using Galera Manager (v1.7.4) and two Debian 11 VMs. The nodes have been installed and are running:

Feb 02, 2023 18:19:04 | galera-manager | [email protected]# echo "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';" | mysql -u mysqld_exporter 2>&1 | grep --color=never wsrep_cluster_status
Feb 02, 2023 18:19:29 | host-stdout    | wsrep_cluster_status	Primary
Feb 02, 2023 18:19:29 | galera-manager | node status is healthy

I can access the nodes with the ssh GUI:

root@LHA01:~# ss -ltp
State             Recv-Q            Send-Q                       Local Address:Port                         Peer Address:Port            Process                                          
LISTEN            0                 128                                0.0.0.0:ssh                               0.0.0.0:*                users:(("sshd",pid=7689,fd=3))                  
LISTEN            0                 4096                               0.0.0.0:4567                              0.0.0.0:*                users:(("mariadbd",pid=13814,fd=8))             
LISTEN            0                 100                              127.0.0.1:smtp                              0.0.0.0:*                users:(("master",pid=4397,fd=13))               
LISTEN            0                 80                                 0.0.0.0:mysql                             0.0.0.0:*                users:(("mariadbd",pid=13814,fd=27))            
LISTEN            0                 128                                   [::]:ssh                                  [::]:*                users:(("sshd",pid=7689,fd=4))                  
LISTEN            0                 100                                  [::1]:smtp                                 [::]:*                users:(("master",pid=4397,fd=14)) 

There are listed in the GUI, but in grey, and 0 joined nodes:

What am I doing wrong?

Thanks in advance

Regards

Hello,

thank you for this new version, I confirm that I have successfully installed on debian 10!

I want to monitor an existing cluster, would you have an updated documentation detailing the procedure (including ssh key configuration, location of the automatically generated key etc ...)

On the other hand, for security reasons, I wonder about the necessity of ssh access to the cluster node.
Is ssh access necessary to monitor the vital signs of the node?
Is this access only needed to eventually deploy a new node?
Is it possible to configure a node without this ssh access which is mandatory in the procedure of adding a node (for example via a file configuration)?

Thanks in advance for your answer,

Cluster database engine: MariaDB 10.6.5

Galera Manager version used: 1.6.2

Browser used: Google Chrome 101.0.4951.54 (official version) 64 bits

Galera Manager host OS: Oracle Linux Server 8.5

Cluster Host OS: Oracle Linux Server 8.5

Cluster node: Unmanaged

Problem type: OS compatibility

Problem description: When configuring the nodes of my Galera Cluster on the Galera Manager, it says there is a compatibility problem between the Galera Manager and the OS of the nodes I want to manage.
My cluster consists of three VM with Oracle Linux Server 8.5, an OS apparently not supported in Galera Manager... But it is RedHat 8 compatible, right?
Since I could install the Galera Manager on a machine with the same OS with no errors and the problem happens when I am trying to add a node to the monitoring, is there a way to workaround this issue?

Checking connection:

Compatibility Error:

I have the skip-name-resolve option enabled on my nodes and am seeing this error in the logs. I believe the issue is that the install process creates 'mysqld_exporter'@'localhost' but not 'mysqld_exporter'@'127.0.0.1'.

May 17 19:48:20 ubuntu-jammy telegraf[9274]: 2022-05-17T19:48:20Z E! [inputs.execd] stderr: "2022/05/17 19:48:20 E! Error in plugin: Error 1045: Access denied for user 'mysqld_exporter'@'127.0.0.1' (using password: YES)"

If I manually change the user's host it is able to connect.

Hello,

I have identified a problem when adding a new node in a cluster monitoring context.
Debian 10 / Mariadb 10.3

The first attempt fails:

The log says:
{"channel-type":"app","cluster-id":"6","file":"/go/pkg/internal/mgmt/units/node.go:829","func":"github.com/codership/galera-manager/pkg/internal/mgmt/units.(*Node).saveDeploymentInfo","host-id":"5","level":"error","msg":"failed to execute cluster config script (RunScriptWithConn): command failed (stepName=__step_no_001, commandId=1, commandType=IncludeCommand): command failed (stepName=__step_no_004, commandId=4, commandType=IncludeCommand): command failed (stepName=create_mysqld_exporter_user, commandId=1, commandType=ExecCommand): failed to set ssh environment variable: ssh: setenv failed","node-id":"5","time":"2021-09-06T12:36:02+02:00"}

To restart the attempt, I delete the file /etc/galera-manager-node, I do not change anything between the two attempts.

The second attempt succeeds:

gm-installer-latest.txt

Some additional information the /etc/default/gmd file isn't being
created.

gm-installer version 1.8.0 (linux/amd64)
CentOS Linux release 7.9.2009 (Core)

Job for gmd.service failed because a configured resource limit was
exceeded. See "systemctl status gmd.service" and "journalctl -xe" for
details.

Aug 12 09:26:58 spare1 systemd[1]: gmd.service
failed to run 'start' task: No such file or directory Aug 12 09:26:58
spare1.projectcluster.co.uk systemd[1]: Failed to start gmd - galera
manager daemon.
Aug 12 09:26:58 spare1 systemd[1]: Unit
gmd.service entered failed state.
Aug 12 09:26:58 spare1 systemd[1]: gmd.service
failed.
Aug 12 09:26:58 spare1 systemd[1]: gmd.service
holdoff time over, scheduling restart.
Aug 12 09:26:58 spare1 systemd[1]: Stopped gmd -
galera manager daemon.
Aug 12 09:26:58 spare1 systemd[1]: start request
repeated too quickly for gmd.service Aug 12 09:26:58
spare1 systemd[1]: Failed to start gmd - galera
manager daemon.
Aug 12 09:26:58 spare1 systemd[1]: Unit
gmd.service entered failed state.
Aug 12 09:26:58 spare1 systemd[1]: gmd.service
failed.

As we don't use IPv6 I had to remove IPv6 from nginx before starting the
installer.

Setting it the permissive got me pass the first error.
/etc/selinux/config

SELINUX=permissive

SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31

thank you for choosing Galera Manager! I am sorry seeing issues with

Galera Manager.

Did SELinux really get disabled? Seems there might have been a failure
in disabling SELinux.

Can you paste output of tool:
sestatus

gm-installer.log

Version: 1.6.2

I just set up Galera Manager using the gmd-in-docker example and am having issues adding an existing cluster. I copied the SSH public key to the nodes' authorized-keys files. However the manager always reports this error:

SSH connection status
unable to connect (ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain)

I even tried connecting from inside the docker container by extracting the SSH private key from the test request and it works without issue.

echo -ne "{private key data}" > ~/ssh-key
chmod 0600 ~/ssh-key
ssh -i ~/ssh-key 192.168.50.10

Here's the error reported in the browser's console:

{
    "msg": "unable to connect",
    "stackTrace": [
        "github.com/codership/galera-manager/pkg/internal/sshcmd.(*Host).Run\n\t/go/pkg/internal/sshcmd/host.go:235",
        "github.com/codership/galera-manager/pkg/internal/sshcmd.(*Host).CheckConnection\n\t/go/pkg/internal/sshcmd/host.go:190",
        "github.com/codership/galera-manager/pkg/internal/mgmt.(*Checker).CheckServerAccess.func1\n\t/go/pkg/internal/mgmt/checker.go:49",
        "github.com/codership/galera-manager/pkg/internal/jobs.(*Processor).Execute.func1\n\t/go/pkg/internal/jobs/processor.go:73",
        "runtime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1371"
    ],
    "wrapped": {
        "msg": "ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain"
    }
}

By default when creating a node it allocates 80gig of disk space, which may not be enough.

I went into aws console and resized the disks and then sshed into each node and did xfs_growfs to workaround.

Allows for GMD Package Repository URL for local repository, but not for InfluxDB. Continues to overwrite the influxDB repo that already exists for local repository and doesn't allow configuration for local repository

From logs

Updating Subscription Management repositories.
Galera Manager 59 kB/s | 2.9 kB 00:00
InfluxDB Repository - RHEL 8 0.0 B/s | 0 B 01:52
Errors during downloading metadata for repository 'influxdb':

• Curl error (7): Couldn't connect to server for https://repos.influxdata.com/rhel/8/x86_64/stable/repodata/repomd.xml [Failed to connect to repos.influxdata.com port 443: Connection timed out]
  Error: Failed to download metadata for repo 'influxdb': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

after it overwrote our inhouse InfluxDB repository repo

I am trying to install Galera Monitor to el9 and got

ERRO[0072] Failed to complete installation: unsupported os

No further info, /tmp/gm-installer.log exists but with length of 0.
My version:
5.14.0-162.6.1.el9_1.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Nov 15 07:49:10 EST 2022 x86_64 x86_64 x86_64 GNU/Linux

Exactly what OS versions Galera Monitor supports a list would be helpful, and is there any workaround like --os-version switch or similar?

Hi All,

I have successfully created an AWS instance of Ubuntu 18.04 and installed Galera Manager. Then I get GM to create a cluster and three cluster nodes. So I end up with 4 instances, the GM and the three nodes. This works perfectly.

I end up with a cluster and the three nodes, but they don't connect. It seems like the Security Groups on AWS are correct, but to be sure I opened up All Traffic, inbound and outbound, on all four instances. So I'm fairly sure the problem is not AWS security.

I can SSH into all four nodes and MariaDB is installed and running (I can log in with 'mysql').

I am using Ubuntu 18.04 and MariaDB 10.3.

If anyone can assist I would be very appreciative. Galera Manager seems like the perfect tool, and I get so very close to success and then the cluster does not connect/work.

Thank you!

basically, when you install gm-installer install and ssh needs upgrading... ubuntu 20.04 lts and also ssh requires interactivity (dpkg unlike rpm can offer interactive -- gm-installer does not allow for interactivity, hence the breakage)

also, the lack of a status update, really hurts the UX.

▉ 2021/10/07 03:38:31 INFO: Upgrading system
2021/10/07 03:38:31 INFO: Executing: apt-get upgrade -y
▎
▋
▊
█
▇
▆ ^C
root@testgmubuntu:~# date
Thu Oct 7 04:07:07 UTC 2021

see the long pause? 3:38:31 to 4:07:07.

no user will wait this long and will stop the process

root@testgmubuntu:/var/log/apt# apt-get upgrade -y
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 9682 (apt-get)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
root@testgmubuntu:/var/log/apt# apt-get upgrade -y
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 9682 (apt-get)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
root@testgmubuntu:/var/log/apt# ps auxw|grep -i apt-get
root 9682 0.2 6.2 74792 63180 pts/0 S 03:38 0:03 apt-get upgrade -y
root 14176 0.0 0.2 8160 2596 pts/2 S+ 04:06 0:00 grep --color=auto -i apt-get
root@testgmubuntu:/var/log/apt# kill -9 9682
root@testgmubuntu:/var/log/apt# apt-get upgrade -y
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
root@testgmubuntu:/var/log/apt# dpkg --configure -a
Setting up openssh-server (1:8.2p1-4ubuntu0.3) ...
rescue-ssh.target is a disabled or a static unit, not starting it.
Setting up shim-signed (1.40.7+15.4-0ubuntu9) ...

fix the manual install, then restart gm-installer install and things work

so today, we found an offending SSH package update. what else might we find?

Fairly new to this tool. Since getting this running with 1.4.3 I ran into the following deployment issue.

The deployment script ran on each of my nodes but stalled on the following

Dec 29, 2021 10:50:23 | host-stdout    | Connecting to github-repository-files.githubusercontent.com (github-repository-files.githubusercontent.com)|185.199.111.154|:443...
Dec 29, 2021 10:50:23 | host-stdout    | connected.
Dec 29, 2021 10:50:23 | host-stdout    | HTTP request sent, awaiting response...
Dec 29, 2021 10:50:23 | host-stdout    | 200 OK
Dec 29, 2021 10:50:23 | host-stdout    | Length: 5730735 (5.5M) [application/x-gzip]
Dec 29, 2021 10:50:23 | host-stdout    | Saving to: ‘latest-linux-amd64.tar.gz’
Dec 29, 2021 10:50:23 | host-stdout    | lates   0%       0  --.-KB/s
Dec 29, 2021 10:50:23 | host-stdout    | latest-linu 100%   5.46M  --.-KB/s    in 0.1s
Dec 29, 2021 10:50:23 | host-stdout    | 2021-12-29 10:50:23 (54.8 MB/s) - ‘latest-linux-amd64.tar.gz’ saved [5730735/5730735]
Dec 29, 2021 10:50:23 | host-stdout    | mysql_wsrep
Dec 29, 2021 10:50:23 | galera-manager | Adding telegraf.conf
Dec 29, 2021 10:50:23 | galera-manager | Adding mysql_wsrep-telegraf-plugin.conf
Dec 29, 2021 10:50:23 | galera-manager | Saving Galera Manager node data
Dec 29, 2021 10:50:23 | galera-manager | Obtaining general_log_file
Dec 29, 2021 10:50:23 | host-stdout    | 172.22.40.90:22$ bash -c 'mysqladmin -u root variables | grep general_log_file | awk '"'"'{print $4}'"'"''
Dec 29, 2021 10:50:23 | galera-manager | failed to execute cluster config script (RunScriptWithConn): command failed (stepName=__step_no_001, commandId=1, commandType=IncludeCommand): command failed (stepName=__step_no_019, commandId=19, commandType=IncludeCommand): command failed (stepName=set_general_log_file, commandId=1, commandType=ExecCommand): failed to set ssh environment variable: ssh: setenv failed
Dec 29, 2021 10:50:23 | galera-manager | Saving Galera Manager node data

The workaround was just to delete the node via the UI and then re-add which seems to allow the deployment to complete properly. (Two checkmarks). However, when running the nodes I only get CPU info and the logs show this repeatedly.

Dec 29, 2021 11:28:10 | mariadb-stage01 | /var/log/mysql/error.log | 2021-12-29 11:28:08 1703 [Warning] Access denied for user 'mysqld_exporter'@'127.0.0.1' (using password: YES)

When viewing the user table I do have the mysqld_exporter user listed.
| mysqld_exporter | localhost | *XXXXXXXXXXXXXXXXXXX |
Seems as if something is not correct with the database access but not sure what to do at this point. Note, I verified I used the correct DB Root password in my cluster setting.

FYI, running mariadb10.3 + Ubuntu 20.04. Locally hosted.

I Want To Know That If Somehow Galera Manager Crashed And Unable To Access To The GUI. What Is The Possible Way To Connect Those Clusters And Nodes To New Galera Manager In Somewhere Else.

Hi,
accidentally I've created a chart that does not have any data:

Now I can't remove it. All other charts which have data are removable.
How can I remove the defective chart?

Hi, I am running a three node Galera MySQL cluster. I have changed the MySQL port from 3306 to 3360 because I am running the Galera Cluster also on the same hosts as my 3 node Docker Swarm (Galera is not running as a container but rather on the host itself). My Docker cluster is also running the HAProxy load balancers and therefore listening on 3306 then backend is pointed to the 3360. This should all work, except what I am seeing is that MySQL/WSREP is trying to start on 3306 to perform the state transfer, then it switches to the custom port afterward. Is this a bug? Or is this just unavoidable?

create a galera manager that runs inside of docker and can also deploy instances inside dockerised containers.

Hi!

User requirement, when they initially deploy, SSH port is 22. But let's say they want to change the SSH port to 2222, there is no way to do this, post-installation. It is a non-editable field. Would be good as not everyone wants to run on the standard port 22.

Just installed galera manager (version 1.8.0) on CentOS 7. After running into multiple issues during install, I managed to finish it. I can access the interface and tried to add my existing cluster.
After adding the first node, and running into the documented issue of set_env failed, I deleted the node again and added it a second time. It worked, however, no data is showing up in the gui.
Checking the logs I see tons of that:

 telegraf: 2022-03-04T12:53:52Z W! [outputs.influxdb] When writing to [http://monitor:8081]: database "gmd" creation failed: 401 Unauthorized

I checked the influxdb and it looks like the user "gmd" was not created as a v1 user, only as a v2 user. Now the telegraf config is based on v1:

[[outputs.influxdb]]
  urls = ["http://monitor:8081"]
  database = "gmd"
  username = "gmd"
  password = "xxxREMOVEDxxx"

but InfluxDB is already version 2.1.

So I changed the config to be v2 and added a "gmd" v2 user, with r/w access to the bucket "gmd".

[[outputs.influxdb_v2]]
  urls = ["http://monitor:8086"]
  token = "xxxREMOVEDxxx"
  organization = "gmd"
  bucket = "gmd"

Notice the port change from 8081 to 8086.

The errors went away but still the gui doesn't show any data. I have a feeling, that the entire setup is somehow broken.

What is the correct procedure to install GM on CentOS 7, which automatically pulls in InfluxDB v2?

Documentation says to open ports 8091 and 8092 in several places, but it should be 9091 and 9092.

This is when setting up the security groups for the management ec2 instance.

Node deployment fails when creating user-provided hosts running CentOS7. Log information is below. I see that MariaDB does get installed but Galera cannot start it.

outside of Github, I was asked:

1)MYSQL_PWD=MYSQL_ROOT_PASSWORD mysqladmin -u root status - what this command shows

[localadmin@osonlybdc1p0665 ~]$ mysqladmin -u root status
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local server through socket '/var/lib/mysql/mysql.sock' (2)'
Check that mariadbd is running and that the socket: '/var/lib/mysql/mysql.sock' exists!
[localadmin@osonlybdc1p0665 ~]$ sudo systemctl start mariadb
[sudo] password for localadmin:
[localadmin@osonlybdc1p0665 ~]$ mysqladmin -u root status
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost''
[localadmin@osonlybdc1p0665 ~]$ mysqladmin status
Uptime: 24 Threads: 3 Questions: 13 Slow queries: 0 Opens: 17 Open tables: 10 Queries per second avg: 0.541
[localadmin@osonlybdc1p0665 ~]$

2)cat /etc/ssh/sshd_config | grep AcceptEnv - what this command shows

[localadmin@osonlybdc1p0665 ~]$ cat /etc/ssh/sshd_config | grep AcceptEnv
cat: /etc/ssh/sshd_config: Permission denied
[localadmin@osonlybdc1p0665 ~]$ sudo cat /etc/ssh/sshd_config | grep AcceptEnv
[sudo] password for localadmin:
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
AcceptEnv MYSQL_PWD
AcceptEnv MYSQL_PWD
AcceptEnv MYSQL_PWD
AcceptEnv MYSQL_PWD
AcceptEnv MYSQL_PWD
AcceptEnv MYSQL_PWD
AcceptEnv MYSQL_PWD
AcceptEnv MYSQL_PWD
AcceptEnv MYSQL_PWD
AcceptEnv MYSQL_PWD
AcceptEnv MYSQL_PWD

I selected MariaDB 10.4 when creating the Cluster but it appears that 10.6 was installed. That's good for me but 10.6 wasn't an option to select and the GUI notes that 10.5 is not supported.

[localadmin@osonlybdc1p0665 ~]$ sudo mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 9
Server version: 10.6.5-MariaDB MariaDB Server

Deployment Log

Jan 04, 2022 06:34:44 | galera-manager | deployment status ok
Jan 04, 2022 06:34:57 | galera-manager | root@osonlybdc1p0665# cat /etc/galera-manager-node
Jan 04, 2022 06:34:57 | host-stdout | cat: /etc/galera-manager-node: No such file or directory
Jan 04, 2022 06:34:57 | galera-manager | Enabling sshd to accept env vars
Jan 04, 2022 06:34:57 | host-stdout | 10.96.41.121:22$ bash -c 'echo -e "\nAcceptEnv MYSQL_PWD\n" >> /etc/ssh/sshd_config'
Jan 04, 2022 06:34:57 | galera-manager | Reloading sshd
Jan 04, 2022 06:34:57 | host-stdout | 10.96.41.121:22$ systemctl restart sshd
Jan 04, 2022 06:34:57 | galera-manager | Waiting for sshd to reload
Jan 04, 2022 06:34:57 | galera-manager | Sleeping for 2 seconds
Jan 04, 2022 06:34:59 | galera-manager | Creating /etc/yum.repos.d
Jan 04, 2022 06:34:59 | host-stdout | 10.96.41.121:22$ mkdir -p /etc/yum.repos.d
Jan 04, 2022 06:34:59 | galera-manager | Writing /etc/yum.repos.d/galera.repo
Jan 04, 2022 06:34:59 | galera-manager | Writing /etc/yum.repos.d/galera-manager.repo
Jan 04, 2022 06:34:59 | galera-manager | Writing /etc/yum.repos.d/influxdb.repo
Jan 04, 2022 06:34:59 | galera-manager | Installing galera
Jan 04, 2022 06:34:59 | host-stdout | 10.96.41.121:22$ yum -y install MariaDB-client MariaDB-server galera
Jan 04, 2022 06:34:59 | host-stdout | Loaded plugins: fastestmirror
Jan 04, 2022 06:34:59 | host-stdout | Loading mirror speeds from cached hostfile
Jan 04, 2022 06:34:59 | host-stdout | base | 3.0 kB 00:00
Jan 04, 2022 06:34:59 | host-stdout | espnxtras | 2.9 kB 00:00
Jan 04, 2022 06:35:00 | host-stdout | galera-manager | 1.4 kB 00:00
Jan 04, 2022 06:35:00 | host-stdout | influxdb | 2.5 kB 00:00
Jan 04, 2022 06:35:00 | host-stdout | mariadb | 3.4 kB 00:00
Jan 04, 2022 06:35:00 | host-stdout | Not using downloaded mariadb/repomd.xml because it is older than what we have:
Jan 04, 2022 06:35:00 | host-stdout | Current : Tue Nov 9 16:42:47 2021
Jan 04, 2022 06:35:00 | host-stdout | Downloaded: Tue Nov 9 16:36:09 2021
Jan 04, 2022 06:35:01 | host-stdout | mariadb-main | 3.4 kB 00:00
Jan 04, 2022 06:35:01 | host-stdout | mariadb-maxscale | 2.5 kB 00:00
Jan 04, 2022 06:35:01 | host-stdout | mariadb-tools | 2.9 kB 00:00
Jan 04, 2022 06:35:01 | host-stdout | puppet | 2.5 kB 00:00
Jan 04, 2022 06:35:01 | host-stdout | updates | 3.0 kB 00:00
Jan 04, 2022 06:35:05 | host-stdout | Package galera is obsoleted by galera-4, trying to install galera-4-26.4.9-1.el7.centos.x86_64 instead
Jan 04, 2022 06:35:05 | host-stdout | Resolving Dependencies
Jan 04, 2022 06:35:05 | host-stdout | --> Running transaction check
Jan 04, 2022 06:35:05 | host-stdout | ---> Package MariaDB-client.x86_64 0:10.6.5-1.el7.centos will be installed
Jan 04, 2022 06:35:05 | host-stdout | ---> Package MariaDB-server.x86_64 0:10.6.5-1.el7.centos will be installed
Jan 04, 2022 06:35:05 | host-stdout | ---> Package galera-4.x86_64 0:26.4.9-1.el7.centos will be installed
Jan 04, 2022 06:35:06 | host-stdout | --> Finished Dependency Resolution
Jan 04, 2022 06:35:06 | host-stdout | Dependencies Resolved
Jan 04, 2022 06:35:06 | host-stdout | ========================================
Jan 04, 2022 06:35:06 | host-stdout | Package Arch Version
Jan 04, 2022 06:35:06 | host-stdout | Repository Size
Jan 04, 2022 06:35:06 | host-stdout | ========================================
Jan 04, 2022 06:35:06 | host-stdout | Installing:
Jan 04, 2022 06:35:06 | host-stdout | MariaDB-client
Jan 04, 2022 06:35:06 | host-stdout | x86_64 10.6.5-1.el7.centos
Jan 04, 2022 06:35:06 | host-stdout | mariadb-main 14 M
Jan 04, 2022 06:35:06 | host-stdout | MariaDB-server
Jan 04, 2022 06:35:06 | host-stdout | x86_64 10.6.5-1.el7.centos
Jan 04, 2022 06:35:06 | host-stdout | mariadb-main 25 M
Jan 04, 2022 06:35:06 | host-stdout | galera-4 x86_64 26.4.9-1.el7.centos
Jan 04, 2022 06:35:06 | host-stdout | mariadb-main 9.6 M
Jan 04, 2022 06:35:06 | host-stdout | Transaction Summary
Jan 04, 2022 06:35:06 | host-stdout | ========================================
Jan 04, 2022 06:35:06 | host-stdout | Install 3 Packages
Jan 04, 2022 06:35:06 | host-stdout | Total download size: 49 M
Jan 04, 2022 06:35:06 | host-stdout | Installed size: 206 M
Jan 04, 2022 06:35:06 | host-stdout | Downloading packages:
Jan 04, 2022 06:35:07 | host-stdout | (2/3): MariaDB- 0% | 0 B --:-- ETA
Jan 04, 2022 06:35:07 | host-stdout | (2/3): MariaDB 45% | 22 MB --:-- ETA
Jan 04, 2022 06:35:07 | host-stdout | (1/3): MariaDB-cli | 14 MB 00:00
Jan 04, 2022 06:35:07 | host-stdout | (2/3): MariaDB-ser | 25 MB 00:01
Jan 04, 2022 06:35:07 | host-stdout | (3/3): galera- 80% | 39 MB 00:00 ETA
Jan 04, 2022 06:35:08 | host-stdout | (3/3): galera-4-26 | 9.6 MB 00:00
Jan 04, 2022 06:35:08 | host-stdout | ----------------------------------------
Jan 04, 2022 06:35:08 | host-stdout | Total 30 MB/s | 49 MB 00:01
Jan 04, 2022 06:35:08 | host-stdout | Running transaction check
Jan 04, 2022 06:35:08 | host-stdout | Running transaction test
Jan 04, 2022 06:35:08 | host-stdout | Transaction test succeeded
Jan 04, 2022 06:35:08 | host-stdout | Running transaction
Jan 04, 2022 06:35:08 | host-stdout | Installing : MariaDB- [ ] 1/3
Jan 04, 2022 06:35:09 | host-stdout | Installing : MariaDB- [# ] 1/3
Jan 04, 2022 06:35:09 | host-stdout | Installing : MariaDB- [## ] 1/3
Jan 04, 2022 06:35:09 | host-stdout | Installing : MariaDB- [### ] 1/3
Jan 04, 2022 06:35:09 | host-stdout | Installing : MariaDB- [#### ] 1/3
Jan 04, 2022 06:35:10 | host-stdout | Installing : MariaDB- [##### ] 1/3
Jan 04, 2022 06:35:10 | host-stdout | Installing : MariaDB- [###### ] 1/3
Jan 04, 2022 06:35:10 | host-stdout | Installing : MariaDB- [####### ] 1/3
Jan 04, 2022 06:35:11 | host-stdout | Installing : MariaDB- [######## ] 1/3
Jan 04, 2022 06:35:11 | host-stdout | Installing : MariaDB-client-10. 1/3
Jan 04, 2022 06:35:12 | host-stdout | Installing : galera-4 [ ] 2/3
Jan 04, 2022 06:35:12 | host-stdout | Installing : galera-4 [# ] 2/3
Jan 04, 2022 06:35:12 | host-stdout | Installing : galera-4 [## ] 2/3
Jan 04, 2022 06:35:12 | host-stdout | Installing : galera-4 [### ] 2/3
Jan 04, 2022 06:35:12 | host-stdout | Installing : galera-4 [#### ] 2/3
Jan 04, 2022 06:35:13 | host-stdout | Installing : galera-4 [##### ] 2/3
Jan 04, 2022 06:35:13 | host-stdout | Installing : galera-4 [###### ] 2/3
Jan 04, 2022 06:35:13 | host-stdout | Installing : galera-4 [####### ] 2/3
Jan 04, 2022 06:35:13 | host-stdout | Installing : galera-4 [######## ] 2/3
Jan 04, 2022 06:35:13 | host-stdout | Installing : galera-4-26.4.9-1. 2/3
Jan 04, 2022 06:35:14 | host-stdout | Installing : MariaDB- [ ] 3/3
Jan 04, 2022 06:35:14 | host-stdout | Installing : MariaDB- [# ] 3/3
Jan 04, 2022 06:35:15 | host-stdout | Installing : MariaDB- [## ] 3/3
Jan 04, 2022 06:35:15 | host-stdout | Installing : MariaDB- [### ] 3/3
Jan 04, 2022 06:35:16 | host-stdout | Installing : MariaDB- [#### ] 3/3
Jan 04, 2022 06:35:16 | host-stdout | Installing : MariaDB- [##### ] 3/3
Jan 04, 2022 06:35:17 | host-stdout | Installing : MariaDB- [###### ] 3/3
Jan 04, 2022 06:35:17 | host-stdout | Installing : MariaDB- [####### ] 3/3
Jan 04, 2022 06:35:18 | host-stdout | Installing : MariaDB- [######## ] 3/3
Jan 04, 2022 06:35:18 | host-stdout | Installing : MariaDB-server-10. 3/3
Jan 04, 2022 06:35:29 | host-stdout | �/usr/bin/my_print_defaults: Can't read dir of '/etc/mysql/wsrep/conf.d/' (Errcode: 2 "No such file or directory")
Jan 04, 2022 06:35:29 | host-stdout | Fatal error in defaults handling. Program aborted
Jan 04, 2022 06:35:29 | host-stdout | �/usr/bin/my_print_defaults: Can't read dir of '/etc/mysql/wsrep/conf.d/' (Errcode: 2 "No such file or directory")
Jan 04, 2022 06:35:29 | host-stdout | Fatal error in defaults handling. Program aborted
Jan 04, 2022 06:35:29 | host-stdout | Verifying : MariaDB-server-10. 1/3
Jan 04, 2022 06:35:29 | host-stdout | Verifying : galera-4-26.4.9-1. 2/3
Jan 04, 2022 06:35:29 | host-stdout | Verifying : MariaDB-client-10. 3/3
Jan 04, 2022 06:35:29 | host-stdout | Installed:
Jan 04, 2022 06:35:29 | host-stdout | MariaDB-client.x86_64 0:10.6.5-1.el7.centos
Jan 04, 2022 06:35:29 | host-stdout | MariaDB-server.x86_64 0:10.6.5-1.el7.centos
Jan 04, 2022 06:35:29 | host-stdout | galera-4.x86_64 0:26.4.9-1.el7.centos
Jan 04, 2022 06:35:29 | host-stdout | Complete!
Jan 04, 2022 06:35:29 | galera-manager | Installing filebeat
Jan 04, 2022 06:35:29 | host-stdout | 10.96.41.121:22$ yum -y install galera-manager-filebeat
Jan 04, 2022 06:35:29 | host-stdout | Loaded plugins: fastestmirror
Jan 04, 2022 06:35:29 | host-stdout | Loading mirror speeds from cached hostfile
Jan 04, 2022 06:35:30 | host-stdout | Resolving Dependencies
Jan 04, 2022 06:35:30 | host-stdout | --> Running transaction check
Jan 04, 2022 06:35:30 | host-stdout | ---> Package galera-manager-filebeat.x86_64 0:1.2.1-1 will be installed
Jan 04, 2022 06:35:30 | host-stdout | --> Finished Dependency Resolution
Jan 04, 2022 06:35:30 | host-stdout | Dependencies Resolved
Jan 04, 2022 06:35:30 | host-stdout | ========================================
Jan 04, 2022 06:35:30 | host-stdout | Package
Jan 04, 2022 06:35:30 | host-stdout | Arch Version Repository Size
Jan 04, 2022 06:35:30 | host-stdout | ========================================
Jan 04, 2022 06:35:30 | host-stdout | Installing:
Jan 04, 2022 06:35:30 | host-stdout | galera-manager-filebeat
Jan 04, 2022 06:35:30 | host-stdout | x86_64 1.2.1-1 galera-manager 7.2 M
Jan 04, 2022 06:35:30 | host-stdout | Transaction Summary
Jan 04, 2022 06:35:30 | host-stdout | ========================================
Jan 04, 2022 06:35:30 | host-stdout | Install 1 Package
Jan 04, 2022 06:35:30 | host-stdout | Total download size: 7.2 M
Jan 04, 2022 06:35:30 | host-stdout | Installed size: 25 M
Jan 04, 2022 06:35:30 | host-stdout | Downloading packages:
Jan 04, 2022 06:35:31 | host-stdout | galera-manager- 0% | 0 B --:-- ETA
Jan 04, 2022 06:35:31 | host-stdout | galera-manager- 5% | 384 kB --:-- ETA
Jan 04, 2022 06:35:32 | host-stdout | galera-manager 30% | 2.2 MB 00:02 ETA
Jan 04, 2022 06:35:32 | host-stdout | galera-manager 89% | 6.4 MB 00:00 ETA
Jan 04, 2022 06:35:32 | host-stdout | galera-manager-fil | 7.2 MB 00:01
Jan 04, 2022 06:35:32 | host-stdout | Running transaction check
Jan 04, 2022 06:35:32 | host-stdout | Running transaction test
Jan 04, 2022 06:35:32 | host-stdout | Transaction test succeeded
Jan 04, 2022 06:35:32 | host-stdout | Running transaction
Jan 04, 2022 06:35:32 | host-stdout | Installing : galera-m [ ] 1/1
Jan 04, 2022 06:35:33 | host-stdout | Installing : galera-m [# ] 1/1
Jan 04, 2022 06:35:33 | host-stdout | Installing : galera-m [## ] 1/1
Jan 04, 2022 06:35:33 | host-stdout | Installing : galera-m [### ] 1/1
Jan 04, 2022 06:35:33 | host-stdout | Installing : galera-m [#### ] 1/1
Jan 04, 2022 06:35:33 | host-stdout | Installing : galera-m [##### ] 1/1
Jan 04, 2022 06:35:33 | host-stdout | Installing : galera-m [###### ] 1/1
Jan 04, 2022 06:35:33 | host-stdout | Installing : galera-m [####### ] 1/1
Jan 04, 2022 06:35:33 | host-stdout | Installing : galera-m [######## ] 1/1
Jan 04, 2022 06:35:34 | host-stdout | Installing : galera-manager-fil 1/1
Jan 04, 2022 06:35:34 | host-stdout | Verifying : galera-manager-fil 1/1
Jan 04, 2022 06:35:34 | host-stdout | Installed:
Jan 04, 2022 06:35:34 | host-stdout | galera-manager-filebeat.x86_64 0:1.2.1-1
Jan 04, 2022 06:35:34 | host-stdout | Complete!
Jan 04, 2022 06:35:34 | galera-manager | Installing telegraf
Jan 04, 2022 06:35:34 | host-stdout | 10.96.41.121:22$ yum -y install telegraf
Jan 04, 2022 06:35:34 | host-stdout | Loaded plugins: fastestmirror
Jan 04, 2022 06:35:34 | host-stdout | Loading mirror speeds from cached hostfile
Jan 04, 2022 06:35:35 | host-stdout | Package telegraf-1.21.1-1.x86_64 already installed and latest version
Jan 04, 2022 06:35:35 | host-stdout | Nothing to do
Jan 04, 2022 06:35:35 | galera-manager | Add filebeat user to the mysql group
Jan 04, 2022 06:35:35 | host-stdout | 10.96.41.121:22$ usermod -aG mysql filebeat
Jan 04, 2022 06:35:35 | galera-manager | Creating /etc/mysql/wsrep/ssl
Jan 04, 2022 06:35:35 | host-stdout | 10.96.41.121:22$ mkdir -p /etc/mysql/wsrep/ssl
Jan 04, 2022 06:35:35 | galera-manager | Saving /etc/mysql/wsrep/ssl/gmnode.pem
Jan 04, 2022 06:35:35 | galera-manager | Saving /etc/mysql/wsrep/ssl/gmnode.key
Jan 04, 2022 06:35:35 | galera-manager | Saving /etc/mysql/wsrep/ssl/gmca.pem
Jan 04, 2022 06:35:35 | galera-manager | Creating /etc/mysql/wsrep/conf.d
Jan 04, 2022 06:35:35 | host-stdout | 10.96.41.121:22$ mkdir -p /etc/mysql/wsrep/conf.d
Jan 04, 2022 06:35:35 | galera-manager | Adding sst ssl config
Jan 04, 2022 06:35:35 | galera-manager | Creating /etc/mysql/wsrep/conf.d
Jan 04, 2022 06:35:35 | host-stdout | 10.96.41.121:22$ mkdir -p /etc/mysql/wsrep/conf.d
Jan 04, 2022 06:35:35 | galera-manager | Including /etc/mysql/wsrep/conf.d in my.cnf
Jan 04, 2022 06:35:35 | host-stdout | 10.96.41.121:22$ bash -c 'echo "!includedir /etc/mysql/wsrep/conf.d/" >> /etc/my.cnf'
Jan 04, 2022 06:35:35 | galera-manager | Including /etc/mysql/wsrep/conf.d in my.cnf
Jan 04, 2022 06:35:35 | host-stdout | 10.96.41.121:22$ yum -y install wget
Jan 04, 2022 06:35:35 | host-stdout | Loaded plugins: fastestmirror
Jan 04, 2022 06:35:35 | host-stdout | Loading mirror speeds from cached hostfile
Jan 04, 2022 06:35:35 | host-stdout | Package wget-1.14-18.el7_6.1.x86_64 already installed and latest version
Jan 04, 2022 06:35:35 | host-stdout | Nothing to do
Jan 04, 2022 06:35:35 | galera-manager | Adding wsrep_provider_options_value
Jan 04, 2022 06:35:35 | galera-manager | Installing telegraf mysql_wsrep plugin
Jan 04, 2022 06:35:35 | host-stdout | 10.96.41.121:22$ bash -c 'wget https://github.com/go-extras/telegraf-mysql-wsrep/files/5233298/latest-linux-amd64.tar.gz && tar -xzvf latest-linux-amd64.tar.gz && mv mysql_wsrep /usr/local/bin/ && chmod +x /usr/local/bin/mysql_wsrep'
Jan 04, 2022 06:35:35 | host-stdout | --2022-01-04 06:35:35-- https://github.com/go-extras/telegraf-mysql-wsrep/files/5233298/latest-linux-amd64.tar.gz
Jan 04, 2022 06:35:35 | host-stdout | Resolving github.com (github.com)...
Jan 04, 2022 06:35:35 | host-stdout | 140.82.113.4
Jan 04, 2022 06:35:35 | host-stdout | Connecting to github.com (github.com)|140.82.113.4|:443...
Jan 04, 2022 06:35:35 | host-stdout | connected.
Jan 04, 2022 06:35:35 | host-stdout | Unable to establish SSL connection.
Jan 04, 2022 06:35:35 | galera-manager | Got an error and attepts = 0
Jan 04, 2022 06:35:35 | galera-manager | failed to execute cluster config script (RunScriptWithConn): command failed (stepName=__step_no_017, commandId=17, commandType=IncludeCommand): command failed (stepName=install_telegraf_mysql_wsrep_plugin, commandId=1, commandType=ExecCommand): Process exited with status 4
Jan 04, 2022 06:35:35 | galera-manager | Saving Galera Manager node data

Hi Support,

I've already establish a set of steps before this and there is no issue arise upon installing, creating a cluster and add up to 3 nodes. Recently, i stumble upon an issue even though its a same steps. The steps are as below

GM Host VM (Ubuntu 20.04)

1. Disable UFW
2. Disable AppArmor
3. Download and Install gm-installer
4. Log in to GM Web
5. Create Unmanaged Cluster
6. Added key to Node
7. Add Node (issue started happening)
8. Error Popup with text 'SSH Connection Status'

Cluster Node (Ubuntu 20.04)

1. Disable UFW
2. Disable AppArmor
3. Add key to /root/.ssh/authorized_keys
4. Reboot

All host and nodes are clean install. No prior application installed before.
Error in System Log tab is "failed to execute info script". However the echo test is successful.

Please advise.

Info on the system and VM used
Cluster database engine - MySQL 8
Galera Manager - Version 1.7.2
Browser Used - Chrome
Galera Manager Host - Ubuntu Server 20.04 (tried with 22.04, gotten same result)
Cluster Host OS - Ubuntu Server 20.04 (tried with 22.04, gotten same result)
Cluster Node - Unmanaged

In the latest version of GMD I cannot add a node since the field for DB IP address is missing. In this version of the GUI I can only enter the IP address for SSH and then the installation fails with the error:

deployment status error: DB IP address must be provided

I have a test host (CentOS 7) with SELinux disabled. The just (2022-03-03) downloaded gm-installer breaks out due to sentenforce comes back with 1 (SELinux disabled)

The log is not helpfule at all:

setenforce: SELinux is disabled

This is all what is inside the log :-(. How to deal with it?

Version 1.7.3 of the GUI

Try to create a "deploy cluster on user provided hosts"

Aim to click copy. It does not copy to clipboard with a failure message - "Couldn't copy public key".

Chrome. macOS.

When Galera Manager creates a new node at Digital Ocean, it allocates a new volume for database storage and mounts it on /var/lib/mysql. However, it does not add this to the /etc/fstab file, so the volume is not automatically remounted at that point on a reboot. This results in a node failure.

I think there are two decent ways to fix this.

1. Add an fstab entry that mounts the volume in a format like: /dev/disk/by-id/scsi-0DO_Volume_gmd-ssazr-xxxx /var/lib/mysql ext4 defaults,nofail,discard 0 0
2. Let the system mount the volume in the standard place in /mnt and make a symbolic link from /var/lib/mysql to the location in /mnt.

would it be possible to create a cross region vpc in aws and use it for replicating data between regions instead of using public ip addresses and sending the data over the internet?

In our staging environment on the server that I run gmd I see a lot of these in syslog. Is this expected? Can I reduce or divert this logging to another file?

Jan  4 11:05:31 galara-manager01 influxd-systemd-start.sh[1082]: [httpd] 192.1.50.91,127.0.0.1 - gmd [04/Jan/2022:11:05:31 -0800] "POST /write?db=gmd HTTP/1.0 " 204 0 "-" "Telegraf/1.21.1 Go/1.17.3" 49a046e4-6d91-11ec-9bff-005056934946 4000
Jan  4 11:05:31 galara-manager01 influxd-systemd-start.sh[1082]: [httpd] 192.1.50.90,127.0.0.1 - gmd [04/Jan/2022:11:05:31 -0800] "POST /write?db=gmd HTTP/1.0 " 204 0 "-" "Telegraf/1.21.1 Go/1.17.3" 49a158fd-6d91-11ec-9c00-005056934946 7331
Jan  4 11:05:32 galara-manager01 influxd-systemd-start.sh[1082]: [httpd] 192.1.50.91,127.0.0.1 - gmd [04/Jan/2022:11:05:32 -0800] "POST /write?db=gmd HTTP/1.0 " 204 0 "-" "Telegraf/1.21.1 Go/1.17.3" 4a3902f8-6d91-11ec-9c01-005056934946 7200
Jan  4 11:05:32 galara-manager01 influxd-systemd-start.sh[1082]: [httpd] 192.1.50.90,127.0.0.1 - gmd [04/Jan/2022:11:05:32 -0800] "POST /write?db=gmd HTTP/1.0 " 204 0 "-" "Telegraf/1.21.1 Go/1.17.3" 4a3a205d-6d91-11ec-9c02-005056934946 6753
Jan  4 11:05:33 galara-manager01 influxd-systemd-start.sh[1082]: [httpd] 192.1.50.91,127.0.0.1 - gmd [04/Jan/2022:11:05:33 -0800] "POST /write?db=gmd HTTP/1.0 " 204 0 "-" "Telegraf/1.21.1 Go/1.17.3" 4ad1bbf3-6d91-11ec-9c03-005056934946 8228
Jan  4 11:05:33 galara-manager01 influxd-systemd-start.sh[1082]: [httpd] 192.1.50.90,127.0.0.1 - gmd [04/Jan/2022:11:05:33 -0800] "POST /write?db=gmd HTTP/1.0 " 204 0 "-" "Telegraf/1.21.1 Go/1.17.3" 4ad2a603-6d91-11ec-9c04-005056934946 3524
Jan  4 11:05:34 galara-manager01 influxd-systemd-start.sh[1082]: [httpd] 192.1.50.91,127.0.0.1 - gmd [04/Jan/2022:11:05:34 -0800] "POST /write?db=gmd HTTP/1.0 " 204 0 "-" "Telegraf/1.21.1 Go/1.17.3" 4b6a55e4-6d91-11ec-9c05-005056934946 3608
Jan  4 11:05:34 galara-manager01 influxd-systemd-start.sh[1082]: [httpd] 192.1.50.90,127.0.0.1 - gmd [04/Jan/2022:11:05:34 -0800] "POST /write?db=gmd HTTP/1.0 " 204 0 "-" "Telegraf/1.21.1 Go/1.17.3" 4b6b32ba-6d91-11ec-9c06-005056934946 5620

Debian 11, bullseye, is now released, and we have user requests for it to be supported as an install target. Please add this, thank you.

https://www.debian.org/News/2021/20210814

I am trying to load a galera cluster with data, using the Loading Physically method, as outlined on https://galeracluster.com/library/documentation/galera-manager-initializing-data.html.

I have Galera Manager freshly installed on Ubuntu Bionic Beaver (18.04 server) and one node, running the same setup. I have gone with the defaults in the installer, only taking into account keyboard localisation.

Installing Galera Manager was painless, as was setting up the first node. I then proceeded with the instructions and started the node from the ellipsis menu and, once synchronised, I then stopped it with the Stop command from the ellipsis menu. When I then tried to restart the node, just to see that it comes up OK before the next step, I got an error message stating that the Galera Manager failed to start it.

The log tab in Galera Manager is empty, i.e., it gives me events up until the shut down. None of my start attempts show in the log -- it remains at the position where it reads [Note] /usr/sbin/mysqld: Shutdown complete.