Voice of the DBA

Tag: AWS

  • Continuity Across Restarts

    There are a lot of database platforms, and each tries to convince you theirs is better. As Brent points out in that link, sometimes they just skip comparing themselves to other platforms because it makes them look better. They only look at the platforms they compete well against.

    For most of us, we often just need basic CRUD operations. I know that most RDBMS platforms would work for us, and sometimes NoSQL ones work as well, though I think that NoSQL isn’t necessarily better for many applications (maybe most). You may feel differently, but that’s my view. While I use SQL Server, I think the majority of systems I’ve managed or built could easily run on MySQL, PostgreSQL, or many other platforms.

    In any case, we want to store some data, get it back, maybe change it, and sometimes delete it. I think that last operation is fairly rare as most of us use soft deletes and because of this, our databases continue to grow like crazy. There was an interesting post from Brent on MySQL in AWS Aurora, where the buffer pool cache can survive a restart of the database engine. This is for the cloud version from AWS, not MySQL in general, but that’s fairly cool to me.

    And scary.

    If you read more, there are some limitations, and the value of this, to me, is limited. However, it’s a neat idea, since I could see some sort of restart of the database from a patch for the engine or even a configuration change. For MySQL, clients can’t connect while the buffer pool is initialized, which isn’t something that we deal with in SQL Server, but I can see this being useful. Or perhaps this helps if an Aurora node goes down and the next one picks up the database engine with a full buffer pool? Not sure if that actually happens from the docs, but if they kept the buffer pool separate enough or up to date on a second node, that would be great.

    In the real world, I wonder to what extent we find an empty buffer pool at startup to be a problem. Sure the first few queries are slow, but most of the workload isn’t the first few queries. It’s all the clients that come in the next 5, 10, 20 minutes.

    As Brent notes, this might not be something we want in SQL Server, but it is good to see cloud-enabled platforms trying something new. Some of those will turn out to not work very well, but for those that do, I bet we see other platforms start to adopt some of the ideas from new technology.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • Custom SQL Server on RDS

    One of the challenges in moving to the cloud is achieving a similar level of performance to what you would get with dedicated hardware on-premises. The cloud is someone else’s computer, and you are limited to the choices that the vendors allow you to rent. In many cases, you might even share the physical hardware resources with other customers, though many cloud providers have started to allow dedicated hardware reservations in the last few years.

    One of the challenges of choosing a PaaS cloud database platform is that there are often restrictions that differ from a similar platform on-premises. This is often to ensure that one customer doesn’t affect another, or that customers don’t make changes that might prevent the vendor from supporting the system. Azure SQL Database gives us a database only, no instance features, though we do see a virtual master database.

    AWS, however, is changing its RDS offering to allow customers to customize their database software. They started with Oracle and then added SQL Server. For the SQL Server offering, they will let you not only change the instance config with things like CLR and install drivers in the host OS. They’ll continue to manage the overall service, and handle backups, DR, etc. You can focus on your database, but if you have special configuration needs, you can set them up.

    This is a nice evolution of the cloud by giving customers more control and meeting their needs, but not forcing them to handle everything. While a lot of technologists don’t think the OS adds a burden to a DBA, I’d disagree. I think the popularity of RDS and Azure SQL Managed Instance show that a lot of customers feel the way I do. Paying for a service to be managed is valuable, and it allows your staff to focus on more helpful tasks, like performance tuning, finding data quality issues, etc.

    Of course, your staff has to take advantage of that extra time. I see plenty of companies that don’t culturally change how they work with their systems, and that means that a lot of the benefits the cloud offers aren’t being seen by the company.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Pause and Backtrack

    One of the main functions for anyone that manages a database is ensuring that they can recover the system in the event of any issues. My view is that restores are the most important skill and task that need to be performed on a database. Since restores require backups, I’d then rank backups as a 1a important task. They’re a dependency and necessity to ensure that we can restore data. Having a set of the data, in a transactionally consistent state just feels critically important to me, over everything else..

    I saw this new feature from Amazon Aurora for their MySQL compatible database. You can use Backtrack to rewind your database to a previous point in time. On one hand that’s an amazing feature. Make a mistake, have an error, click a few buttons and get the database restored back to the minute (or second) when you made a mistake. On the other hand, if you delete a table, do you want to roll all tables back to that point in time?

    This seems like an amazing feature. Amazon takes some of the hassles of managing some backups backups. You determine how far back you want to go, in hours, up to three days. Depending on the activity in your database, they charge differently. To me, that’s interesting. It makes sense to me as a customer. I do more, they track more, I pay more. This also seems to be a way to capture more money for Amazon by cutting some of the consumer surplus that exists with flat fee pricing, which is something many of us prefer.

    The way this works is also different than Azure. The Azure point in time feature allows you to go back, but you can’t restore on top of your existing database. You’d need to restore elsewhere, then play the rename game or move data between databases. While that seems inconvenient, if you’ve ever had someone restore a local SQL Server backup over a database you needed, you might appreciate the safeguards of not allowing a restore on top of an existing database. While the process might seem like a hassle, this does help prevent mistakes during a stressful situation.

    Which of these do I like? I prefer the Azure one, though I’d like the restores to be more granular than a minute. The reason is that I rarely want to restore in a disaster over the existing database. In most applications I’ve managed, there are updates to multiple parts of the database. A mistake in one table doesn’t necessarily mean that data changed in other tables should be discarded. Even during deployments, when things go wrong, I’ve often just broken one set of tables and rolling back the entire database in a restore is painful. Usually I’d prefer to undo what I can and get the any missing data from a restored copy of my database.

    Perhaps it’s just me, but I find the idea of allowing clients, or even many technical people, to easily roll back an entire database after a mistake to be very dangerous. By the time we recognize the mistake, verify data, notify others, we might have lots of changes in many tables. Abandoning that data for the sake of convenience is something that’s unnecessary. I also worry many people trying this feature don’t think through the implications of rolling back an entire database. If you feel differently, let me know. There are cases this is certainly helpful, but I think I’d rather have a “restore to a new db and rename both” automated task instead of AWS Backtrack.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.3MB) podcast or subscribe to the feed at iTunes and Libsyn.