Questions tagged with Amazon Aurora
Content language: English
Sort by most recent
Someone deleted rows from the critical table of RDS Aurora MySQL Instance. We don't have anything in slow query log either. Is there any other way to find out or trace all the query that ran against RDS aurora Instances?
Hello,
I want to implement "active-active" replication, like it is described here https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2 , but using multi-az feature created read instances/replicas. As far as i understood, if im using just "multi-az" then i dont have access to the created "secondary" database. In "multi-az cluster" and "aurora cluster", i do have "read" access to the "secondary" database replicas. Is it possible to get "cmd" access into them? Is it possible to implement some manual changes with cmd access? Is it possible to get the "binlog" location, and using it, setup the "active-active" replication, between the "primary" and "standby"? Or there are some limitations, that make it impossible?
Thanks
How do i migrate RDS encrypted cluster to another aws account?
1. Its encrypted DB
2. its a cluster
Based on above,
1. Sharing snapshot wont work
2. copy clustered DB snapshot is not available yet
3. manual export import is not an option
Please suggest ways
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 [1]. Please be aware that your cluster will experience a short period of downtime when the update is applied.
Visit the Aurora Version Policy [2] and the documentation [3] 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 [4].
[1] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.PostgreSQL.html
[2] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.html
[3] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Updates.20180305.html
[4] https://aws.amazon.com/support
I am using the Aurora Blue/Green deployment process to upgrade by database from mySQL5.7 to mySQL8.0.26. This also is upgrading the Aurora engine from 2 to 3.
The upgrade fails due to a pre-check failure:
```
{
"id": "engineMixupCheck",
"title": "Tables recognized by InnoDB that belong to a different engine",
"status": "OK",
"description": "Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removes InnoDB table files manually from the disk and creates e.g. a MyISAM table with the same name.\n\nA possible way to solve this situation is to e.g. in case of MyISAM table:\n\n1. Rename the MyISAM table to a temporary name (RENAME TABLE).\n2. Create some dummy InnoDB table (its definition does not need to match), then copy (copy, not move) and rename the dummy .frm and .ibd files to the orphan name using OS file commands.\n3. The orphan table can be then dropped (DROP TABLE), as well as the dummy table.\n4. Finally the MyISAM table can be renamed back to its original name.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "mysql.general_log_backup",
"description": "recognized by the InnoDB engine but belongs to CSV"
}
]
}
```
As an Aurora user, it is not possible for me to delete, move, move, alter or change any tables in the `mysql` tablespace, so the recommend remediation is not possible.
So my question is, how can I force the Blue/Green process to skip this check, or even better, how can I manually DROP the `mysql.general_log_backup` table as I do not need it?
Please note I am using "FILE" based logging the DB parameters.
Steps to reproduce:
- Create an aurora instance with Engine version 5.7.mysql_aurora.2.10.3
- start a blue green deployment with
* engine version 8.0 and aurora3+
* use custom cluster parameter group
* use custom instance parameter group
- Blue Green environment created
- DB Engine Upgrade fails
Thanks!
Hi,
I am using AWS Backup to create a snapshot of my Aurora Postgres cluster + instance. In Resource assignments I added arn of cluster and arn of the instance. But backup is only doing a backup of a cluster? So I have one cluster restored but with 0 instances. Why AWS Backup does not backup my RDS instance?
Thanks
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?
Would it be possible to setup an Aurora serverless v2 in us-east-1 and have a read replica in another region (us-west-2)? How could we do this via console?
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:
and another example:
When this happens, on insert, I get errors like this
```
Caused by: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '214' for key 'PRIMARY'
Caused by: PDOException: SQLSTATE[23000]: 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?
Aurora MySQL serverless 1 is no longer supported (for creation), yet all of the documentation is still pointing towards serverless v1. I am using MySQL serverless v2 with secrets manager and I have a python module that is able to connect to the writer endpoint alright without RDS proxy. For following the lambda function examples, I have created an RDS proxy, however I am finding a hard time finding reliable lambda code examples, especially in javascript that can successfully connect to my Aurora serverless v2. The goal is to have this connection be triggered by cognito events.
Querying from redshift to serverless aurora in cross account facing error as Timeout Expired,Debug Driver logs from
com.amazon.redshift.core.v3.QueryExecutorImpl.receiveErrorResponse: <=BE ErrorMessage(ERROR: timeout expired
Location: File: ../src/external_catalog/external_catalog_api.cpp, Routine: localize_external_table, Line: 1267
Server SQLState: D;600)
Cross account set up well verified:Anoynomus details below
nc -vz auroradnsname.rds.amazonaws.com 5432
Connection to auroradnsname.rds.amazonaws.com 5432 port [tcp/postgres] succeeded!
P.S :Instead of VPC peering using aws transit gateway
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!