Questions tagged with Amazon Aurora
Content language: English
Sort by most recent
We are planning on exploring MyRocks database engine of MySQL.
I am aware that AWS RDS MariaDB supports it but haven't found any article if it's not supported by Aurora MySQL Compatible.
Is this available and will it be available in the future?
Thanks!
I want to upgrade my Aurora cluster from v2.08.03 (current version) to v2.11.1.
According to the instructions here (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html ) using the console I should "change the Aurora MySQL engine version in the DB engine version box".
BUT in the DB engine version box I find only one option: Aurora MySQL (compatible with MySQL 5.7.2.08.3).
In addition, in the Maintenance section I don't find the option "Enable auto minor version upgrade setting".
we have our data in AWS RDS postgres db. We have a table with around 100-200 rows and we loaded up 200M rows in 3 hours timeframe. That table is indexed as well. And now we want to insert more data into the table and we see that adding 20M rows is taking 5 hours.
Our instance size is db.r6g.xlarge. And we have two AZ. I want to know the reason for slower performance in query operation and what is the best way to import that huge data into postgres table.
We have noticed a sudden increase in costs generated by our RDS Aurora MySQL Serverless v2 clusters that we cannot understand, and would like some help in resolving this issue.
Around February 18th, we noticed that the capacity metric on our instances was not decreasing its capacity to a minimum at night when no one was using it. Before this date, our clusters would usually maintain a minimum of 0.5 ACU during off-peak hours. However, after February 18th, the capacity stayed the entire night at 1.5 ACU, and later to 1 after we capped the max capacity at night.
We have followed the instructions recommended by some users and turned off Performance Insight, but the problem still persists. We could not find any queries generated by a user in the logs of the night where no one usually uses the system, only the ones executed internally by RDS.
We suspect that the reason for the sudden increase in costs may be due to an internal change that AWS made to the service. If this is the case, we would appreciate any information you could provide us on this change so that we can optimize our resources and reduce costs wherever possible.
We would be grateful if you could investigate this matter and provide us with a prompt response. We rely on your expertise to help us resolve this issue and continue to use AWS services effectively.
Thank you for your attention to this matter.
I need to change the default timezone of AWS Aurora PostgreSQL cluster from UTC to CST. We can change it by creating a custom cluster parameter group and then use it in the cluster.
Now my question is what will happen during daylight savings? Will there be any impact of daylight savings to the DB cluster? Do we need to make any change regarding daylight savings in the cluster, instance? Do we need to reboot the cluster?
Please suggest.
The New database behaving slow and taking long time for application to come up running on container, and hence crashing the application.
is there any way to speed up the database process to allow the application to cache all the data from the DB to memory and start the application ?
We are experiencing a strange delay in CPU Utilization and DB Connections metrics for any new created aurora mysql db instances. Once the instance is created the metrics data is available as usual but within a time the delay is increasing. After a couple of days the delay is already about 2 hours.
Engine version: 5.7.mysql_aurora.2.11.1
Instance type: db.r5.xlarge
Region: eu-west-1
This is how it looks like comparing to the old instances. The orange line is the new instance.
All other metrics are up to date.
CPU Total for enhanced monitoring is also working normally.
Due to such delay it is not possible to create an alarm and CPU column does not show value on the database page.
We have tried to create several new instances in different availability zones. The same issue for any of them.
Has anyone experienced something like that? What can we do to resolve that?
I have read most, all?, of the AWS troubleshooting guides on RDS/Aurora and we tried a bunch of things. We have a cluster with one reader and one writer. About two days ago they failed over and flipped automatically. Not sure why, not even sure it's related, but it happened and we didn't notice because things kept humming along. This morning, however, our apps, and IDEs started receiving too many connection errors when trying to connect. We could connect directly to the read instance, but couldn't write. Rebooted both, waited for the writer instance to recover, and same issue. Failed over to flip the instances, no real change. Flipped back, no change. Rebooted the writer again, no change. As we finally gave up and started restoring a snapshot, write connections just resumed on their own. There was about a half hour gap between the previous reboot and no additional event logs that would indicate it just took a while to reboot or failover.
This feels like there was an AWS issue, but of course I don't see anything mentioned in the health dashboard. Our max connection param was set to the default for this version of MySQL and worked out to 90 for the db.t2.medium's we're running on. According to Cloudwatch we have never seen much more than about 15, so it seems odd that we were even receiving too many connection errors.
It would be great to know what changed to break things and then how they were resolved because right now I have a working instance but no real clue as to what may have changed this morning. Any ideas?
Hi,
I tried following [this procedure](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3) to import the data of a MySQL 8.0 instance running on my development laptop, through S3, to a new Aurora MySQL v3 cluster.
First issue was that I had to use Percona XtraBackup 8.0, since 2.4 does not support MySQL 8.0.
Then, creating the new cluster through the Console gives me the following validation error:
> You can't restore to aurora-mysql 8.0.mysql_aurora.3.02.2 from an S3 backup of mysql 8.0.
This used to work from a local MySQL 5.6 to an Aurora MySQL v1, but, unfortunately, that version is now EOL.
I can't see any references to MySQL 8.0 on the page linked above, nor from the similar [CLI operation page](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html).
Does this mean restoring from S3 is not available for Aurora MySQL v3?
If so, what are the alternatives?
My use case is to spin up a replica of our whole production environment, using locally prepared test data, from a single (terraform) command.
Also, maybe it would be good to update the various documentation to explicitly state that MySQL 8.0 is not supported, since I imagine a lot of people had to migrate to it, following the EOL of 5.6.
Cheers,
Cyril.
I am getting **PDO::prepare(): MySQL server has gone away** error in my error logs.
After the RDS Aurora mysql version upgrade i am getting this error simultaneously.
I am not able to find the root cause of this error. current version of mysql is 2.10.3.
I follow this post but no luck.
https://aws.amazon.com/premiumsupport/knowledge-center/rds-mysql-server-gone-away/
asked a month ago
I am trying to export a snapshot to an S3 bucket, from our Aurora Postgres Serverless v2 cluster. I keep getting the following error message: "The specified db snapshot engine mode isn't supported and can't be exported."
AFAICT from the user guide, Serverless v2 does support exporting snapshots to S3: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-export-snapshot.html
Our engine is Aurora PostgreSQL, version 10.21, region is eu-west-1, encrypted.
In the CLI doc for [creating db instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) and [creating db cluster ](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html), it is mentioned that if publicly accessible flag is not specified explicitly, then the behavior is dependent on DBSubnetGroupName being specified or not. In my case, I specified the DBSubnetGroup which consists of public subnets and yet, the db instances created were not publicly accessible.