Questions tagged with Aurora MySQL
Content language: English
Sort by most recent
Aurora upgrade 2 to 3 / MySql 5.7 to 8.0: potential bug in pre-check validation (depreciated words)
We have noticed that the pre-checks for the upgrade of MySQL 5.7 to MySQL 8 are having issues with character combinations that "resemble" depreciated words. For example, the depreciated "Group By ... DESC" is one of those constructs "[https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html#USER_UpgradeDBInstance.MySQL.57to80Prechecks]()" "There must be no queries and stored program definitions from MySQL 8.0.12 or lower that use ASC or DESC qualifiers for GROUP BY clauses." While our stored procedures use Group by's, there is no associated "DESC" word with them. However, the character sequence does appear in the stored procedure in various forms: * There is a call to another stored procedure called "update_fc**desc**ription();". It has the characters "desc" within the name * There are columns in the queries (table columns) with the name "blah**Desc**riptionblah" * There is a block comment that has the word "**Desc**ription:" that describes the stored procedure (documentation) However, there are no "DESC" words associated with the "Group by". For testing, * I deleted the comments word, and that issue no longer appeared as an error * I renamed the call to the other stored procedure update_fc**desc**ription(); to update_fc**dxexscxrixp**tion();, and that issue no longer appeared as an error * The columns that have the characters "desc" I couldn't work around without a lot of changing to the stored procedure It seems that there is a Stackoverflow question outlining this behavior too: [https://stackoverflow.com/questions/71412470/aws-mysql-aurora-major-version-2-3-upgrade-pre-checks-obsolete-procedure]() Also, a "re:Post" question too: [https://repost.aws/questions/QUWJzlcpitRoGM0woZVOylBQ/aurora-2-to-3-mysql-5-7-to-8-0-upgrade-pre-check-incorrect-validation-on-store-procedure]() This is clearly a bug in the pre-check process and is limiting our upgrade from MySQL 5.7 to 8. Any updates on this being fixed/addressed? Thank you.
Best practice for restoring an RDS Aurora snapshot into a CloudFormation-built solution
Hi experts, I'm looking for best practices in restoring data into a cloudformation-built system. I've got extensive cloudformation that builds a solution, including an RDS Aurora Serverless database cluster. Now I want to restore that RDS server from a snapshot. - I notice that restoring through the console creates a new cluster, and this is no longer in the cloudformation stack, so doesn't get updates (plus my existing RDS instance is retained) - I found the property `DbSnapshotIdentifier` in DBInstance along with this answer https://repost.aws/questions/QUGElgNYmhTEGzkgTUVP21oQ/restoring-rds-snapshot-with-cloud-formation, however I see in the docs that I can never change it after the initial deployment (it seems it will delete the DB if I do - see below). This means I could never restore more than once. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-rds-database-instance.html#cfn-rds-dbinstance-dbsnapshotidentifier - I also found a StackOverflow post from 6 years ago with the same question but no real answers. https://stackoverflow.com/questions/32255309/how-do-i-restore-rds-snapshot-into-a-cloudformation For the DbSnapshotIdentifier point above, here's the relevant wording from their docs that concerns me: > After you restore a DB instance with a DBSnapshotIdentifier property, you must specify the same DBSnapshotIdentifier property for any future updates to the DB instance. When you specify this property for an update, the DB instance is not restored from the DB snapshot again, and the data in the database is not changed. However, if you don't specify the DBSnapshotIdentifier property, an empty DB instance is created, and the original DB instance is deleted It seems this should be simple but it's not. Please don't tell me I need to fall back to using `mysqlbackup` ¯\\_(ツ)\_/¯ Thanks in advance, Scott
AWS DMS Duplicate entry error
I'm running AWS DMS task in full load + ongoing replication mode, both source and target are aws aurora mysql. Target database was created by cloning source and truncating all tables to preserve the schema. For one of the tables replication always fails with following error: ``` 2022-06-23T17:12:05 [TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 23000 NativeError: 1062 Message: [MySQL][ODBC 8.0(w) Driver][mysqld-5.7.12-log]Duplicate entry '1213210-50' for key 'PRIMARY'  (ar_odbc_stmt.c:4828) ``` I have verified that there is no duplicates in source database table, the tables have identical schema in both source and target, and both source and target table has primary key with auto increment. The only workaround I found was to drop the table on target db and let DMS create it, but DMS creates it without indexes and foreign keys that we need. Is there any fix for this error that would allow me to preserve the table schema?
Missing Aurora wait event reference
I was look on performance_schema for a specific database and i struggle to find any information inside the [documentation](https://docs.amazonaws.cn/en_us/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.html#AuroraMySQL.Reference.Waitevents) for the specific wait **synch/cond/sql/FILE_AS_TABLE::cond_request** Does somebody can explain me what it is ? Thanks in advance, Alexis
Time Duration to Setup Server less Aurora V2 Postgre SQL database cluster
Just trying to figure out the time duration to setup the "Time Duration to Setup Server less Aurora V2 Postgre SQL database cluster" with single DB instance in a private subnet "Default settings", single availability zone cluster, no replica to be created basic backup retention.
CRITICAL: Aurora Serverless V2 writer node failing
We run a large eCommerce site in which the production database cluster was recently migrated to Aurora MySQL Serverless V2 from V1. In the last week and a half, we've observed two identical complete failures of the Writer Serverless V2 node. All attempts to connect to the RDS node fail with the message: "Too many connections" yet prior to the incident, Cloudwatch logs confirm ~30 connections (typical for the time in the night it happens) and as soon as it happens, the connections drop to 0 and remain there. We have custom parameter groups which set the max_execution_time to 20s, so any long-running SQL/connections will have ended and been closed as seen from the Cloudwatch logs and Audit logs we export to Cloudwatch too. During the outage, no auto-scaling is occurring and no auto-recovery happens. We have to manually reboot the Writer instance to get the cluster/website back online. Hoping this will catch the eye of someone from AWS who can look into this ASAP.
wordpress connection error in rds from ec2
They are two EC2 virtual machines, which use wordpress, both connect to an RDS Database, which one of the virtual machines began to mark a connection error. Both have the same security group, the connection ports were verified. The machine that has the error can connect to other databases. The error only occurs when connecting to RDS.
Next Aurora MySQL version release?
We've discovered a production impacting bug in MySQL that affects all Aurora MySQL v3 versions. The issue has been fixed in MySQL v8.0.26. Aurora MySQL v3 is based off v8.0.23. When could we expect the next version of Amazon Aurora MySQL version 3? and what version of MySQL 8 will it be based off? **Bugs** 1. https://bugs.mysql.com/bug.php?id=103710 2. https://bugs.mysql.com/bug.php?id=103711
Aurora MySQL Cluster - Massive increase in bytes used
I recently noticed our Aurora MySQL cluster's Bytes Used increased massively from 341 GiB, to 4362 GiB over the course of five days. The backup logs look like this: | Date | Size | | --- | --- | | May 19, 2022, 8:39:13 AM UTC | 4362 GiB | | May 18, 2022, 8:35:52 AM UTC | 4362 GiB | | May 17, 2022, 8:41:40 AM UTC | 4100 GiB | | May 16, 2022, 8:40:30 AM UTC | 2997 GiB | | May 15, 2022, 8:37:08 AM UTC | 1791 GiB | | May 14, 2022, 8:36:58 AM UTC | 583 GiB | | May 13, 2022, 8:39:09 AM UTC | 341 GiB | | May 12, 2022, 8:36:12 AM UTC | 341 GiB | As you can see it rises sharply for a few days and then levels off. There is no operational reason for this to have happened because our database size is only about ~40 GiB. I upgraded the cluster engine from `2.08.2` to `2.10.2` hoping that the dynamic resizing would take care of the issue, but the bytes used is still showing over ~4000 GiB. I have rebooted the cluster, but that has made no difference. Through some research there are a few other resources, but none of them have any real resolution as to this exact issue: * [Why Volume Bytes Used become so high on AWS Aurora RDS MySQL cluster?](https://serverfault.com/questions/1074597/why-volume-bytes-used-become-so-high-on-aws-aurora-rds-mysql-cluster) * [How to stop auto expanding of Aurora's storage (volume)](https://serverfault.com/questions/979791/how-to-stop-auto-expanding-of-auroras-storage-volume) * [Why is my "volume bytes used" always increasing on my Amazon Aurora cluster?](https://serverfault.com/questions/873699/why-is-my-volume-bytes-used-always-increasing-on-my-amazon-aurora-cluster?noredirect=1&lq=1) * [How do I view the total storage used for my Amazon Aurora MySQL DB cluster?](https://aws.amazon.com/premiumsupport/knowledge-center/view-storage-aurora-cluster/) **Engine version:** 5.7.mysql_aurora.2.10.2