I have a few DB snapshots that I made on Amazon RDS from a couple years ago. I'm trying to restore those DB snapshots but when I select the snapshot and click "Restore from DB Snapshot" I get the error:
"Cannot find version 5.1.42 for mysql"
I first thought this was because I didn't have an instance running, so I went to DB Instances, Launched DB Instance, and created one of the same size as this snapshot. However, the oldest MySQL that is available is 5.1.45 so that's what I used. I was able to connect to it from my local machine and I confirmed it had no data within it.
Then I went back to my DB Snapshots and tried again and I still receive the same error even though I now have a DB instance running.
What do I need to do to restore this?
(I'm doing this all from the aws web UI)
That's an 'interesting' (and worrisome) problem - section DB Engine Version Management within chapter MySQL Database Engine in the Amazon RDS Technical FAQ seems to imply that restoring an unsupported MySQL snapshot might not be possible anymore in fact (even though it is nowhere stated explicitly):
Does Amazon RDS provide guidelines for supporting new MySQL version releases and/or deprecating MySQL versions that are currently
supported?
[...]
We intend to support major MySQL version releases, including MySQL
5.1, for 3 years after they are initially supported by Amazon RDS.
We intend to support minor MySQL version releases (e.g. MySQL 5.1.45)
for at least 1 year after they are initially supported by Amazon RDS.
After a MySQL major or minor version has been “deprecated”, we expect
to provide a three month grace period for you to initiate an upgrade
to a supported version prior to an automatic upgrade being applied
during your scheduled maintenance window.
[emphasis mine]
According to Impossible to create a RDS instance in EU-west, MySQL 5.1.42 has been deprecated as of May 24, 2011 the latest already, so this three month grace period has long passed.
Obviously the apparent effect of this deprecation you encountered (i.e. the inability to restore respectively outdated snapshots) will come to a surprise for many, so there might be options to deal with it eventually still, but I'm afraid you'll need to contact AWS for a solution, either directly or via the Amazon Relational Database Service Forum - please post your findings as an answer here if possible, insofar I'd expect this problem to show up regularly as time goes by.
Related
We use RDS MySQL with a micro service architecture. Each service has its own database and we have been slowly moving them into their own instances for load management and whatnot.
We have a replica still attached to the primary instance (where most of the databases still reside) but it is missing the databases that are on their own instances. We would like to have a single read replica that sources from all of the instances so that we can run sanity checks on the data without needing to move data between instances.
Does RDS support a multi source read replica? Or will we need to manage our own MySQL install in order to accomplish this?
As far as I know, you will have to operate MySQL yourself on EC2 to get the multi-source replication feature. You may like to contact your AWS support representative to confirm this.
AWS RDS does not support multi-source replication. Configuring replication from an external master is limited because you have to configure it using a stored procedure provided by AWS. It does not have any support for configuring multiple replication channels. Each replica has exactly one master.
AWS Aurora 2.x (API-compatible with MySQL 5.7) also does not support multi-source replication. As of Aurora 2.07.x, they list multi-source replication among features of MySQL 5.7 they do not support. See https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.2070.html
AWS Aurora 1.x (API-compatible with MySQL 5.6) has something they call multi-master cluster, where all the nodes in a cluster can be writers. I have not used this, and I don't know how reliable it is. See https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-multi-master.html for details.
It's weird that they seem to have lost functionality between Aurora 1.x and 2.x. My understanding is that they sort of "started over" with Aurora 2.x, and some features haven't been implemented in the new version yet.
This is my understanding as of December 2019. Of course future versions may add such features.
I have two questions:
is MySQL 5.7 is old ?
what the best version of mysql for Rails 5.2 ?
Thanks!
No, it is not the latest, but is still supported (up to October 2020, extended support up to October 2023)
best is the one that's compatible and satisfies your requirements (and is supported)
Obviously you'd start new apps with most current one, but unless you desperately need some new feature - do not rush the upgrade.
Prior to upgrading - make sure you're not using any deprecated features (official manual is your friend - https://dev.mysql.com/doc/refman/8.0/en/upgrading.html), have a good tests coverage, performance and error monitoring. Also have your team available during the upgrade, so that you'll have someone to help if something unexpected happens (like an error that did not show up in tests).
Upgrade options:
With a downtime - just make a backup, schedule downtime during usual lowest load time, bring your app down and upgrade server inplace (may take long for large databases, thus not for everyone)
With (hopefully) much less downtime - mysql supports replication to next version (5.7 -> 8.0 in this case) given both servers are GA-releases. You can create a 8.0 slave and make it the master once it is fully in sync. This way you only need to stop database writes during switching servers (heavily depends on your app, but a few minutes of downtime is still an option).
We are looking to upgrade our RDS Mysql From 5.7 to 8.0.11. When try to modify and upgrade the instance from AWS UI we get a
Database instance is in a state that cannot be upgraded: PreUpgrade checks failed: RDS detected Incompatibilities upgrading to MySQL 8.0.15. More details can be found in the PrePatchCompatibility.log file, accessible in the 'logs' section below.
error in the recent events area but when we download the PrePatchCompatibility.log the only messages we see are
3) Usage of utf8mb3 charset
The following objects use the utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support.
More Information:
https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html
schema.table.column - column's default character set: utf8
I've looked this message up and the compatibility issues associated with it and this is supposed to be a warning. The bottom of the log shows
Errors: 0
Database Objects Affected: 261
From everything I've Read this should work.
Has anyone successfully upgraded from mysql 5.7 to 8.0 in aws RDS? Would I actually have to change all of my columns from utf8mb3 to utf8mb4 or is there something else going on?
After contacting AWS support team, they disabled pre-upgrade checks for our instance. After which we were able to upgrade successfully from 5.7 to 8.0.
They have informed that AWS has a bug and patch for that is ready and will be released soon. Though they didn't provide any ETA for the same. But in case you are in hurry, you can contact them ask for the private patch (or disabling pre-upgrade checks in this case).
RDS MySQL Engineer here.
This post was sent to us by an RDS customer, so I thought it would be interesting to chime in and provide you some visibility about this issue. Our team is aware of this issue, and a patch deployment was scheduled to address it. This fix will be transparent to all of our RDS MySQL customers, and will require no additional action from your side once it is released.
I would like apologize for any inconvenience this may have caused you and reiterate that we appreciate you bringing this issue to our attention, we have listened :)
With that said this may be a good time to remind you that our team is constantly monitoring our AWS Official channels such as #aws (Twitter), AWS RDS MySQL Forums (forums.aws.amazon.com/forum.jspa?forumID=60) and our support tickets of course.
We recommend you using these channels if you are looking for a faster response from us.
Best regards, Your friends from the RDS MySQL team.
We have recently upgraded from MySQL 5.7 to 8.0 on AWS RDS.
Due to lack of knowledge we have gone for the default parameter group.
Two main results so far:
Firstly, the read replica seems to lose FreeStorageSpace. Under 5.7, both the master and the replica used to have identical graphs on CloudWatch. Now the read replica line drops quickly away from the master. In our instance the read replica is of smaller size than the master, but this has never been an issue.
Secondly (and less importantly), Performance Insights doesnt seem to work. When clicking on it, it just shows "No Active sessions in selected time range". Have removed and readded it, but makes no difference.
Does anyone have a few recommended changes to the default parameter group and/or any ideas what might be causing the two issues above?
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html
"Amazon RDS Performance Insights is not supported for MariaDB version 10.0, 10.1, or 10.3, or for MySQL version 5.5 or 8.0."
I’m working on a relatively small application, serving about 1,500 users and running on a Mysql database that is about 300 megs. The entire system runs on AWS with a single dedicated EC2 node running the Grails application on Tomcat 8 and a single dedicated Mysql RDS instance. The system has been running live in production for about three years with no database issues. The two largest tables contain about 40k records. The application is built using Grails and Java 1.7.
Yesterday our application began throwing the following exception, with the underlying error message of:
"Got error 28 from storage engine"
The logs available from the RDS admin web console are empty.
Googling has not revealed any promising leads that have helped us resolve the issue, other than most messages point out that the disk is out of space. Given that most search results refer to disk space. Being software developers rather than DBA's with significant Mysql expertise, we boosted the storage space of the Mysql RDS instance. Unfortunately, today our application is still sporadically throwing the same exception. Having created our Mysql DRS instance with 15 gigs of space -- which is several orders of magnitude of additional space than our application makes use of -- we are at a lost as to what is the root cause of this issue. Our guess is that there is possibly some out of the box Mysql limitation that we are hitting up against but have no idea what it may be or how to solve it. Indeed, the whole reason we host onRDS was to avoid issues of this type.
Doing some Googling, this seems like a somewhat common Mysql error but that does not have any concrete trail for us to follow. Most suggestions talk about checking the filesystem or "inode" space. Given that this is a hosted Mysql RDS instance on AWS, I am unsure if or how to check such things. Looking at the CloudWatch for the RDS instance, I can see that the CPU is idle and that the instance is dramatically under the 15 gig storage limit.
Does anyone have any suggestions for us to investigate?
Given that we are new to RDS, can you please point us to any documentation or -- even better -- suggest what settings we can tweak in the RDS console -- to help prevent this error from occuring? Ideally, we moved to RDS thinking that if this was a mysql sizing or scaling issue that moving to RDS would solve the problem. As a last resort, this morning we then deleted about 20k rows of unessential data. Unfortunately, the issue persists and we continue to experience the issue.
A few questions:
Are there any RDS settings we can adjust to avoid this issue?
Can this be solved by moving to a larger RDS instance, perhaps with more memory?
Would we experience this issue if we moved to Aurora?
Well from your comment this is definitely a low on storage issue. Because 13 Gb is very less storage. you can check the free available storage in the dashboard. Check this screenshot below in the "Storage" metric under monitoring if it goes ahead of the red line you will start getting Error 28. You will have to increase the storage of your RDS instance or free up some space. I will suggest increase the storage to avoid this issue in future.