Linode Managed Databases now available

[Sim]

After running in beta for a few months, Linode's Managed Database solution is now available.

Currently has MySQL support only (v5.7 and v8.0), with PostgreSQL, MongoDB and Redis coming soon.

Available in 1 node, 2 node and 3 node configurations - you can have a highly available database solution with simple setup and management - full daily backups included (7 day retention). You get rull root permissions for your MySQL instance - but no access to the underlying servers it runs on.

I haven't tried their database servers yet, so I'm not sure how it will compare performance-wise to the self-contained LEMP servers I currently run on my Linode VPS machines. A 3 node configuration sounds really nice - but it gets expensive very quickly.

I'm kind of curious to see whether I could deploy a single database cluster and run most of my sites off that - allowing me to downsize my various VPS machines which don't tend to require the amount of processing power I end up giving them just to have enough RAM to run MySQL.

I'm not sure I'd actually save any money though.

Anyone tried Linode's managed database service yet?

 

[MattW]

I ran it in Beta, worked OK, with no real issues (but wasn't really "stressed" much). I wouldn't really be wanting to run it in production though now, as you've pointed out, it gets expensive pretty quickly.

 

[eva2000]

Same tried it while in Beta and was okay. Being a control freak means giving up full root user system control wasn't fun as you'd be limited by what you can really do with just MySQL root user permissions

But yup gets expensive when your InnoDB data set reaches a size that requires those higher Linode Managed MySQL memory/storage based plans - especially compared to bare metal dedicated servers at that price. However, in comparison to bare metal alternatives, folks are overlooking Linode VPS and Managed MySQL databases have disk redundancy and resilience. To get the equivalent on bare metal, folks will start needing raid 10 or better and multiple disk setups, which would blow out comparative costs.

I haven't tried their database servers yet, so I'm not sure how it will compare performance-wise to the self-contained LEMP servers I currently run on my Linode VPS machines. A 3 node configuration sounds really nice - but it gets expensive very quickly.

I don't think performance alone would be the underlying reason to opt for Linode Managed MySQL - as MySQL server performance will always be relative to the underlying hardware + MySQL/system configuration settings that are dialled in to match the app's MySQL usage requirements and the users acceptable hosting budget.

The lowest dedicated CPU Linode Managed MySQL 4GB plan with 2 CPU core and 80GB in 3 node setup will be US$195/month. Now if you have between 2-3GB InnoDB dataset size requirements, that would be fine. But if you had 4-8GB InnoDB data set size requirements but were limited to that ~US$195/month budget, then you'd be potentially getting poorer performance sticking with the dedicated CPU Linode Managed MySQL 4GB plan with 2 CPU core and 80GB in 3 node setup will be US$195/month as opposed to using a regular Linode VPS - like dedicated CPU 16GB plan with 8 CPU cores and 320GB disk at US$120/month.

The only use case I see for Linode Managed MySQL is for higher potential uptime and availability. I guess if you're running a for-profit business where your direct income is dependent on high availability, then the extra cost is justified.

 

[Sim]

I don't think performance alone would be the underlying reason to opt for Linode Managed MySQL

Yes, I was more thinking along the lines of what you pointed out in your post - I was assuming that performance would not be as good as a well-tuned database running on a standalone VPS, but it was curious as to exactly how much worse off things would be?

I would have thought that the three node setup would give more than just higher availability, but would also be used in a load-balanced configuration (for reads at least) - which would help performance, despite not having as much RAM available as we can on a single VPS in a cost-effective manner? Or is that not a valid assumption?

I guess if you're running a for-profit business where your direct income is dependent on high availability, then the extra cost is justified.

Yes to for-profit business here - but I'm not really at the size where the potential revenue lost from database outages and downtime will exceed the likely costs of a correctly sized managed database deployment, so I guess I'll have to make do with my self contained LEMP boxes for now.

I'm currently running my busiest site on a single 8GB Linode, but I'm pushing the limits of memory and will soon have to upgrade. I was dreading the jump to a 16GB machine with all of its additional processing power and storage that I simply don't need.

Perhaps it's time for me to consider a 24GB High Memory instance to run my DB on and a smaller VPS for the web server? Then again, a 24GB high memory instance will probably be powerful enough to run the site perfectly well on its own, with some attached storage.

 

[eva2000]

Yes, I was more thinking along the lines of what you pointed out in your post - I was assuming that performance would not be as good as a well-tuned database running on a standalone VPS, but it was curious as to exactly how much worse off things would be?

Depends on the MySQL workloads and the difference between reading/writing from disk versus from memory when it comes to being system memory starved and not being able to service the InnoDB buffer pool requirements.

I'm currently running my busiest site on a single 8GB Linode, but I'm pushing the limits of memory and will soon have to upgrade. I was dreading the jump to a 16GB machine with all of its additional processing power and storage that I simply don't need.

Linode Managed MySQL databases probably won't help with that unless you're willing to increase your hosting costs well beyond the normal single Linode VPS upgraded server.

 

[Sim]

Depends on the MySQL workloads and the difference between reading/writing from disk versus from memory when it comes to being system memory starved and not being able to service the InnoDB buffer pool requirements.

Yes, that's the assumption I've been working on - that allocating sufficient InnoDB buffer pool is critical to obtaining best performance.

NVMe drives will certainly have decreased the gap between memory and disk access speeds, but nowhere near closed it.

 

[eva2000]

Yes, that's the assumption I've been working on - that allocating sufficient InnoDB buffer pool is critical to obtaining best performance.

NVMe drives will certainly have decreased the gap between memory and disk access speeds, but nowhere near closed it.

Yup. Though with an external Managed MySQL database setup, it's easier to test and compare - just clone your production Linode vps as a test web end server + load up your forum data onto a test 3 node Linode Managed MySQL setup that is memory starved and then do some benchmarks on the cloned Linode web + Managed MySQL database setup and leave your production live site untouched to compare benchmark/work loads. Linode VPS cloning is one of the fav features I like about Linode

 

[Sim]

and then do some benchmarks

Any suggestions on a good way of executing said benchmarks on an XF site?

 

[eva2000]

Any suggestions on a good way of executing said benchmarks on an XF site?

Logging Xenforo MySQL queries and playing them back on cloned setup could give you some rough ideas with the clone setup switching between normal MySQL and 3 node Managed MySQL servers. There's a few tools out there that can help. Percona had Percona Playback tool but seems to have stopped development. slowql tool looks good https://github.com/devops-works/slowql

cat slowq.log-copy
/usr/sbin/mysqld, Version: 10.3.34-MariaDB (MariaDB Server). started with:
Tcp port: 3306  Unix socket: /var/lib/mysql/mysql.sock
Time                Id Command  Argument
# Time: 220504 13:43:14
# User@Host: root[root] @ localhost []
# Thread_id: 8  Schema:   QC_hit: No
# Query_time: 0.000424  Lock_time: 0.000110  Rows_sent: 1  Rows_examined: 1
# Rows_affected: 0  Bytes_sent: 85
SET timestamp=1651686194;
SELECT FROM_UNIXTIME(UNIX_TIMESTAMP() - variable_value) AS server_start FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE variable_name='Uptime';

Parsing and summarizing slow query log at slowq.log-copy

digest -f slowq.log-copy -k mariadb
INFO[0000] log file has 10 lines                       
INFO[0000] digest duration: 226.939µs                   
INFO[0000] parsed 1 queries                             
INFO[0000] found 1 different queries hashs             

=-= Server meta =-=

Binary              : /usr/sbin/mysqld
Port                : 3306
Socket              : /var/lib/mysql/mysql.sock
Version             : 10.3.34-MariaDB
Version short       : 10.3.34
Version description : MariaDB Server

Digest duration     : 226.939µs
Real duration       : 0s

Bytes handled       : 85

=-= Queries stats =-=

Sorted by: random, increasing
Showing top 3 queries

Query #1
Calls                  : 1
Hash                   : d329bd02c28b7aed6f1f1bc0936dec9c
Fingerprint            : select from_unixtime(unix_timestamp() - variable_value) as server_start from information_schema.global_status where variable_name = ?;
Schema                 :
Min/Max/Mean time      : 424µs/424µs/424µs
p50/p95                : 424µs/424µs
Concurrency            : +Inf%
Standard deviation     : 0s
Cum Query Time         : 424µs
Cum Lock Time          : 110µs
Cum Bytes sent         : 85
Cum Rows Examined/Sent : 1/1
Cum Killed             : 0

INFO[0000] saving results in cache file                 
ERRO[0000] cannot save results in cache file: json: unsupported value: +Inf

playback on the same server, not a different server, so speed factor is naturally 1

replayer -u $DBUSER -password $DBPASS -h ${DBIP}:${DBPORT} -k mariadb -f slowq.log-copy -db $DBNAME -no-dry-run -w 1 -show-errors
INFO[0000] getting real execution time                 
INFO[0000] 1 workers will be created                   
WARN[0000] no-dry-run flag found, queries will be executed
INFO[0000] replay started on Wed May 4 14:00:57         
INFO[0000] estimated time of end: Wed May 4 14:00:57   
0 / 1 [....................................................................................................................................................................................................] ? p/s 0s 0.00%
INFO[0000] replay ended on Wed May 4 14:00:57           

=-= Results =-=

Replay duration:  1.503689ms
Real duration:    0s
Log file:         slowq.log-copy
Dry run:          false
Workers:          1

Database
  ├─ kind:      mariadb
  ├─ user:      root
  ├─ use pass:  false
  └─ address:   127.0.0.1:3306

Statistics
  ├─ Queries:                1
  ├─ Errors:                 0
  ├─ Queries success rate:   100.0000%
  ├─ Speed factor:           1.0000
  ├─ Duration difference:    n/a
  └─ Replayer speed:         -+Inf%

Note: the replayer may take a little more time due to the numerous conditions that are verified during the replay.

 

[dknife]

Aren't managed databases more about easy instance creation and redundant failover to completely separate mirrored instances?

If it's anything like RDS, read speeds are usually very fast but there's a write penalty.

 

[VersoBit]

Yeah so with Linodes Managed product, this is just a HA failover. I recently had a master node go down and we had a seamless switch to the backup nodes. We even got credited for the month because of the failover. So far I am very happy/impressed with Linode as we used to be diehard Digital Ocean users.

 

[eva2000]

Aren't managed databases more about easy instance creation and redundant failover to completely separate mirrored instances?

Yup essentially, my sentiment in previous post

Yeah so with Linodes Managed product, this is just a HA failover. I recently had a master node go down and we had a seamless switch to the backup nodes. We even got credited for the month because of the failover. So far I am very happy/impressed with Linode as we used to be diehard Digital Ocean users.

Nice. Curious why the master node went down though, did you figure out why? Does Linode give any insights for such scenarios? That's what I'm curious about - with a non-managed regular server based MySQL instance, you'd be able to dig into that and see why it went down and learn what to do to ensure it stays up. Guess for Managed MySQL it doesn't matter to some extent, as HA failover will just ensure your MySQL usage continues running.

 

[VersoBit]

did you figure out why?

Yeah, so the node that was hosting the "master" database had a failure that required intervention. Nothing crazy i'd honestly say, that's why we spun up a HA node.

 

[eva2000]

Yeah, so the node that was hosting the "master" database had a failure that required intervention. Nothing crazy i'd honestly say, that's why we spun up a HA node.

Ah host node failure - guess you can't plan for that usually which makes Linode Managed MySQL usage case more appealing.