Hacker News Reader

Comment by MichaelRenor | Hacker News Reader

Especially considering that all of AWS database solutions require a 20 minute maintenance window per week!

The RDS service is literally scripted EC2 instances running MySQL/Postgres/SQL Server etc. Anything you do in the RDS console/API runs (or schedules) scripts on EC2 instances. If you would have downtime on any maintenance of your self-managed DB instance (say, upgrading the DB engine), so will RDS.

Some people get disillusioned at this fact, thinking RDS was something more magical. But AWS does offer the Multi-AZ option, which does the maintenance on the standby, fails over, and then performs the same on the main instance. It's effectively transparent. RDS also makes backups, restores (including point in time), encryption using KMS etc. really easy. If you don't have a full-time DBA, RDS provides for a very easy to use DB with virtually no maintenance required, but Multi-AZ is absolutely required for any kind of production deployment.

AWS's answer to Cloud Spanner is much more likely to be a future cross-region replicating version of DynamoDB or Aurora, not RDS.

As far as Multi-AZ is concerned, it's a bit of a wash. A month ago when the east coast had its issues, Multi-AZ didn't do anything. Every time I need to reboot an instance, with failover it is down/inaccessible for the same amount of time as if I had just rebooted it plainly.

I'm sure there's scenarios where it's worked well for people, but I've never seen it happen.

I see multi region saves many disasters. Multi AZ seems a waste. What percent of failures only hit 1 AZ? Your loss is for sure (higher latency, bandwidth cost).... unclear what the real world gain is of multi AZ.

What are they doing during those 20 minutes?

Define "maintenance window" - the DB becomes read-only? Or unreachable? This sounds insane to me.

Not usually, but it sometimes will go offline for 5 or 10 minutes or more. It fails over essentially.

Actions that require database downtime/restarts can happen during the maintenance window. For example, if you change a DB parameter that requires a database restart, you can tell AWS to restart the DB during the next maintenance window. Same goes for DB engine upgrades and the like.

If you're running anything production-worthy, you'll be using one of AWS's multi-AZ/failover solutions for your production RDS instances. In that case, the database will perform a failover in those instances so there isn't downtime.

That depends on the parameter being changed; not all parameter changes are compatible with block level replication. Such as the MySQL InnoDB log file size, something that needs to be changed on every instance.

> In that case, the database will perform a failover in those instances so there isn't downtime.

Have you done that? I have and there's been downtime every time (~5m).

That doesn't mean they're unavailable for 20 minutes weekly, probably because of the nature of AWS's multi-AZ RDS setup.

At our shop, we haven't had any problems with RDS maintenance at all -- and we would indeed get paged for even 1 minute of database downtime, much less 20 (!). That said, we don't have that sort of monitoring in place for any of the test/staging DBs (which are not multi-AZ).

That's a window when they _can_ do maintenance, it's pretty rare for them to actually do it.

The SLA document [0] says 99.95% so perhaps you meant per month?

0 - https://aws.amazon.com/rds/sla/

You see the trick here, that's 99.95% outside of their regularly scheduled maintenance!

Oh! Now I see. I haven't used RDS for anything critical yet but thought it'd be a no-brainer.

insert mind expanding gif

In practice it works just fine. They just make you give them permission to blow your app up for twenty minutes a week (and wink and say maybe they won't actually do it this week).

With respect to SLA's the two important things in my opinion are:

* How precisely is it measured? * What happens if it is not met?

As observed by the other posters, scheduled maintenance doesn't count.

Reply on news.ycombinator.com