We're Hiring!

Mattermost, Inc.

Any way to avoid ping test on remote DB?

I’m installing Mattermost on Debian 10 and using MySQL on a remote server with filtered ports, so ping wouldn’t be allowed even for open doors. I’m not the DB admin - these instances are managed by the hosting provider.

It’s not a limitation tho; I have been using these host-managed databases on other self-hosted services in some of my VPS (which are from the very same provider - it’s Greenhost if it rings any bell). It’s been not long since the last time I used them on homologation by the way. So this doesn’t have nothing to do with the actual connection being made, but the ping test before that, I suppose?

I could run a local instance just for that (as in Posgres New Install on Ubuntu 20.04 - Failed to Ping DB - #5 by XxLilBoPeepsxX), however it would be better for security, management and replication purposes to keep my database away from the Mattermost host server.

Datasource entry should be like:

"DataSource": "mysql://******@213.*.*.*:*************@tcp(213.*.*.*:3306)/self_generated_db_name?charset=utf8mb4,utf8\u0026sslmode=disable\u0026connect_timeout=10"

Console and log are already on debug level and they show no more than this:

{"level":"info","ts":1621363217.4548242,"caller":"app/server.go:245","msg":"Server is initializing...","go_version":"go1.15.5"}
{"level":"info","ts":1621363217.4550266,"caller":"app/web_hub.go:83","msg":"Starting websocket hubs","number_of_hubs":4}
{"level":"debug","ts":1621363217.4623725,"caller":"app/web_hub.go:388","msg":"Hub is starting","index":0}
{"level":"debug","ts":1621363217.4623973,"caller":"app/web_hub.go:388","msg":"Hub is starting","index":1}
{"level":"debug","ts":1621363217.4624314,"caller":"app/web_hub.go:388","msg":"Hub is starting","index":2}
{"level":"debug","ts":1621363217.462482,"caller":"app/web_hub.go:388","msg":"Hub is starting","index":3}
{"level":"info","ts":1621363217.4652076,"caller":"i18n/i18n.go:93","msg":"Loaded system translations","for locale":"en","from locale":"/srv/mattermost/i18n/en.json"}
{"level":"info","ts":1621363217.471392,"caller":"sqlstore/store.go:282","msg":"Pinging SQL","database":"master"}
{"level":"error","ts":1621363227.471789,"caller":"sqlstore/store.go:294","msg":"Failed to ping DB","error":"dial tcp 213.*.*.*:3306: i/o timeout","retrying in seconds":10}
{"level":"info","ts":1621363237.4720788,"caller":"sqlstore/store.go:282","msg":"Pinging SQL","database":"master"}
{"level":"error","ts":1621363247.4725316,"caller":"sqlstore/store.go:294","msg":"Failed to ping DB","error":"dial tcp 213.*.*.*:3306: i/o timeout","retrying in seconds":10}
{"level":"info","ts":1621363257.4728866,"caller":"sqlstore/store.go:282","msg":"Pinging SQL","database":"master"}
{"level":"error","ts":1621363267.4732037,"caller":"sqlstore/store.go:294","msg":"Failed to ping DB","error":"dial tcp 213.*.*.*:3306: i/o timeout","retrying in seconds":10}
{"level":"info","ts":1621363277.4734955,"caller":"sqlstore/store.go:282","msg":"Pinging SQL","database":"master"}

nmap -Pn on the db server:
nmap -Pn 213...*
Host discovery disabled (-Pn). All addresses will be marked ‘up’ and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-05-18 15:29 -03
Nmap scan report for _.greenhost.nl (213...)
Host is up.
All 1000 scanned ports on _.greenhost.nl (213.
..) are filtered

Nmap done: 1 IP address (1 host up) scanned in 202.46 seconds

I appreciate any thoughts on this (and if a local instance is the only way, I’ll just let it be)