Questions tagged with Amazon Relational Database Service
Content language: English
Sort by most recent
[Action Required] Upgrade Amazon Aurora PostgreSQL 11.13, 11.14, 11.15, 12.8, 12.10, 13.4, 13.5, and 13.6 minor versions by September 15, 2023
Newer versions of Amazon Aurora PostgreSQL-compatible edition are now available and database cluster(s) running Aurora PostgreSQL minor versions 11.13, 11.14, 11.15, 12.8, 12.10, 13.4, 13.5, and 13.6 need to be upgraded by September 15, 2023. These newer minor versions include important updates that will improve the operations of your Aurora PostgreSQL instances and workloads. We strongly encourage you to upgrade to at least a recommended minimum minor version at your earliest convenience. * For PostgreSQL Minor Version 11.13, 11.14, and 11.15, the recommended minimum minor version is 11.18. * For PostgreSQL Minor Version 12.8 and 12.10, the recommended minimum minor version is 12.13. * For PostgreSQL Minor Version 13.4, 13.5 and 13.6, the recommended minimum minor version is 13.9. Starting on or after 12:00 PM PDT on September 15, 2023, if your Amazon Aurora PostgreSQL cluster has not been upgraded to a newer minor version, we will schedule the relevant recommended minimum minor version to be automatically applied during your next maintenance window. Changes will apply to your cluster during your next maintenance window even if auto minor version upgrade is disabled. Restoration of Amazon Aurora PostgreSQL 11.13, 11.14, 11.15, 12.8, 12.10, 13.4, 13.5, and 13.6 database snapshots after September 15, 2023 will result in an automatic upgrade of the restored database to a supported version at the time. How to Determine Which Instances are Running These Minor Versions? * In the Amazon RDS console, you can see details about a database cluster, including the Aurora PostgreSQL version of instances in the cluster, by choosing Databases from the console's navigation pane. * To view DB cluster information by using the AWS CLI, use the describe-db-clusters command. * To view DB cluster information using the Amazon RDS API, use the DescribeDBClusters operation. You can also query a database directly to get the version number by querying the aurora_version() system function i.e., "SELECT * FROM aurora_version();". How to Apply a New Minor Version You can apply a new minor version in the AWS Management Console, via the AWS CLI, or via the RDS API. Customers using CloudFormation are advised to apply updates in CloudFormation. We advise you to take a manual snapshot before upgrading. For detailed upgrade procedures, please see the available User Guide . Please be aware that your cluster will experience a short period of downtime when the update is applied. Visit the Aurora Version Policy  and the documentation  for more information and detailed release notes about minor versions, including existing supported versions. If you have any questions or concerns, the AWS Support Team is available on AWS re:Post and via Premium Support .  https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.PostgreSQL.html  https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.html  https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Updates.20180305.html  https://aws.amazon.com/support
We are processing a cube on a Microsoft SQL RDS SSAS installation and it's failing for the below: Failed to save modifications to the server. Error returned: 'OLE DB or ODBC error: Query timeout expired; HYT00. OLE DB or ODBC error: Operation canceled; HY008. This can be fixed by changing the ExternalCommandTimeout and ExternalConnectionTimeout analysis server properties. I tried doing it through SSMS and a XMLA script and got access denied messages. Is there a way to adjust these properties for a managed Microsoft SQL server SSAS RDS instance?
Hi Team, I have two RDS Postgres instances in Oregon and Ireland region Both RDS instances are on the engine version 9.6.12. We need to upgrade this version to Postgres engine version 13.3. We tired multiple ways to upgrade the database version upgrading first to minor version 9.6.22 to upgrading to major version 9.6.12. However, when preforming the minor version upgrade, it does not show the list of version available to upgrade in the versions and when trying to upgrade to another minor version, the parameter group for the RDS instance is grayed out. Therefore this is a blocker for us to upgrade the database.![Enter image description here](/media/postImages/original/IMbPaKYzF4Q7ej6vNFp6dHPA) The screenshot of the error is attached. Appreciate your guidance.
I have a snapshot of a MySQL 5.6.35 instance that I want to restore, but it seems like this is no longer possible, I just get the following message when trying to restore the snapshot from the AWS console : RDS does not support creating a DB instance with the following combination: DBInstanceClass=db.m6i.large, Engine=mysql, EngineVersion=5.6.35, LicenseModel=general-public-license. For supported combinations of instance class and database engine version, see the documentation. Is there any other way to retrieve the database contents from the snapshot? Or is there a way to upgrade the snapshot itself to MySQL 5.7?
I have an RDS instance using MySQL engine version 5.7.36. RDS recommends updating to a newer minor 5.7 engine version, but no versions are available to choose when modifying the instance. describe-db-engine-versions doesn't list 5.7.36, but does list 5.7.34 and 5.7.37, and newer versions after that. Snapshots taken from the instance cannot be restored, because creating a new instance using the version the snapshots specify is not allowed. 5.7.36 is still documented on https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Concepts.VersionMgmt.html as supported until April 2023. As far as I can see there are no notifications that it's deprecated. There was a Health notification in January of impending end of support but no indication of this behavior: > Starting March 20, 2023 00:00:01 AM UTC, you will not be able to create new RDS instances with MySQL minor versions 8.0.27, 8.0.26, 8.0.25, 8.0.23, 5.7.36, 5.7.34 and 5.7.33 from either the AWS Console or the CLI. We recommend you to upgrade your databases before April 20, 2023. RDS will upgrade your MySQL databases running minor versions 8.0.27, 8.0.26, 8.0.25, 8.0.23, 5.7.36, 5.7.34 and 5.7.33 as well as any instances restored from the snapshots of these versions to the latest minor version during a scheduled maintenance window between April 20, 2023 00:00:01 UTC and May 20, 2023 00:00:01 UTC. On May 20, 2023 00:00:01 AM UTC, any MySQL databases running minor versions 8.0.27, 8.0.26, 8.0.25, 8.0.23, 5.7.36, 5.7.34 and 5.7.33 that remain will be automatically upgraded to the latest minor version by RDS regardless of instances’ scheduled maintenance window. So, upgrades should be available until April 20, and even today new instances should still be able to be created with these versions. Every other version listed in the notification is still currently available, except 5.7.36. To me this indicates an error or mistake on the part of AWS. What are my options here?
Im trying to follow this guide https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2 , for \*active\*-\*active\* replication. But on command `CHANGE *active* TO *active*_HOST=....` i get error: `ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or REPLICATION_*secondary*_ADMIN privilege(s) for this operation` As i understood AWS forbids this kind of access via command line access. So, how do i then do this change? i assume via `parameters group`... but how? \*active\* = some non inclusive word \*secondary\* = some other non inclusive word
We using RDS Read replica For Production DB. RDS Read Replica taken more Storage than main DB . Prod Storage : 81 GB Read Replica: 1000GB Even now we are getting the recommendation to increase the storage even more . Why does it take more storage? How to reduce the storage size without affecting read replica. It also afflicted our prod DR process and cost wise. confirm we promote the Read Replica DB to Main DB it take same amount of storage.
Hi, I'm trying to create a copy of an Aurora PostgreSQL cluster snapshot in a different region using the aws cli, I was able to do it five times, but now I'm getting the error message **Cannot copy more than 5 snapshots concurrently to the same region**. I suspect that the problem was that I deleted those snapshots while they were being copied and for some reason the status was never updated. ##### Question: do I have to contact the technical support so that they can update the status of the snapshots in the region or is there a way to clean up the snapshots that were deleted before copy them?
current scenario 1 MysqlRDS with 8TB of an instance. After migrating some application log tables, it was found that: - We are allocating an unnecessary 6TB, as the total size of the database is approx. 2TB AWS does not yet provide means to downsize allocated storage. what is the need - migrates the database to another instance in the same region with the storage already adjusted and thus freeing us from paying for an unnecessary 6TB of storage, What is the best strategy for a bank with this volume, operating with 2 read replicas, 24 hours a day, 365 days a year.
Hello there, I'm trying to drop a DB on the Aurora, but the requests just hangs. I've tried several times and the last attempt has been runnning for 600 seconds. it's a tiny DB of 20MB gzipped. * running `show databases;` returns the borken_db in the list. * running `use broken_db;`now hangs too. * running `show processlist`returns the following: | Id | User | Host | db | Command | Time | State | Info | |----|-----------------|-----------------|-------------|---------|------|----------------------------------|-----------------------------| | 5 | event_scheduler | localhost | | Daemon | 8310 | Waiting on empty queue | | | 19 | rdsadmin | localhost | | Sleep | 0 | | | | 21 | rdsadmin | localhost | | Sleep | 1 | | | | 22 | rdsadmin | localhost | | Sleep | 1 | | | | 25 | rdsadmin | localhost | | Sleep | 252 | | | | 36 | root_user | 10.0.0.48:36768 | broken_db | Sleep | 2404 | | | | 38 | root_user | 10.0.0.48:36788 | mysql | Query | 2736 | Waiting for schema metadata lock | DROP DATABASE `broken_db` | | 47 | root_user | 10.0.0.48:36826 | mysql | Query | 2346 | Waiting for schema metadata lock | drop DATABASE broken_db | | 50 | root_user | 10.0.0.48:36854 | | Query | 1990 | Waiting for schema metadata lock | USE `broken_db` | | 51 | root_user | 10.0.0.48:36874 | mysql | Query | 0 | init | show processlist | | 52 | root_user | 10.0.0.48:36894 | mysql | Query | 1042 | Waiting for schema metadata lock | use broken_db | | 58 | root_user | 10.0.0.48:36922 | | Query | 178 | Waiting for schema metadata lock | use broken_db | | 59 | rdsadmin | localhost | | Sleep | 7 | | | where do I go from there?
For the last few days, I am trying to upgrade an RDS SQL Server web-edition instance from db.t2.small to db.t3.small. but every time i receive the following error. *We're sorry, your request to modify DB instance xxx has failed. Cannot modify the instance class because there are no instances of the requested class available in the current instance's availability zone. Please try your request again at a later time.* I have also used AWS CLI to check the orderable db-instances describe-orderable-db-instance-options This returns command also shows that orderable instances are available in us-east-1 with instance type as db.t3.small , but still i am unable to change the instance type. Is anyone facing the same issue or has a solution to this ?
I have +20 RDS Aurora MYSQL clusters, each with a read and write replica. On each of these clusters I have many databases (thousands), and on each database I have a of table like this: ``` CREATE TABLE `projects` ( `id` INT(11) NOT NULL AUTO_INCREMENT,... ``` Sometimes, the AUTO_INCREMENT value of this table gets out of sync on the read and write replica. An example: ![autoincrement issue](/media/postImages/original/IMNRhZ-DpxRIqzR_5LB07V5Q) and another example: ![autoincrement issue](/media/postImages/original/IM9A6IFDg5TJan4nEDLqLkUQ) When this happens, on insert, I get errors like this ``` Caused by: PDOException: SQLSTATE: Integrity constraint violation: 1062 Duplicate entry '214' for key 'PRIMARY' Caused by: PDOException: SQLSTATE: Integrity constraint violation: 1062 Duplicate entry '16' for key 'PRIMARY' ``` The only fix available is a cluster failover, that is switch read and writer replicas. After failover the values are synchronized and the insert works. Does anyone else have this issue? Is this the right place to post this issue so that the AWS developers know about and maybe fix it?