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.
Related
mysql is a common database and it supports kinds of configuration and tune parameters such as character_set_server, innodb_log_file_size and so on. These backend parameters are set under e.g. /etc/mysql/mysql.cnf configuration file and below the [mysqld] section, and take effect after service mysql restart.
There exists a situation where a single mysql server is providing database service for more than one application (on the same physical machine), and each of the applications may has its own officially recommended backend parameter settings.
However, it may happens when the parameters of different applications differ from each other and it may become worse when there are conflicts between application settings, for example, app A needs utf8 as the character encoding method and app B is using another one.
So, is there any mysqld configuration method to support this situation, or the right way is to start multiple mysql instances with each tuned for one application.
Thanks a lot!
I found the mysqld_multi solution from mysql official site solved my problems, which can start multiple mysqld processes and each one could has its own configurations.
I am trying to use Binlog feature of mysql to capture changes and feed them to DWH. (my requirement is not for replication).
By looking at official documentation (https://dev.mysql.com/doc/refman/8.0/en/replication-binlog-encryption.html) - "From MySQL 8.0.14, binary log files and relay log files can be encrypted.."
Does it mean it's not there for versions 5.x ?
I am trying to enable Binlog for mysql 5.x instances, and wanted to make sure of security.
can I assume it is impossible to have encrypted bin logs for mysql 5.x ?
As i went through the 5.7 documentation , it (encryption) is no where mentioned (https://dev.mysql.com/doc/refman/5.7/en/binary-log.html)
I may try to keep the Binary logs for 2 days probably as I am using Nifi to fetch these logs using CaptureChangeMySQL processor and load them to Data warehouse (DWH).. once the DWH is populated, i dont need the logs anymore.
Please help me with your suggestions or understanding..
The version of mysql 5.7 is also possible, and SSL is recommended. Of course, the encryption of statements like DML/DDL is also related to the binlog_fromat parameter.
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.
The MySQL 5.7 documentation makes reference to, and describes, a program called mysql_ssl_rsa_setup, which is supposed to make SSL certificate and key generation for encryption much "easier".
I cannot find this anywhere in the source distribution, so my guess is that it hasn't been added to the 5.7 distribution yet. Has anyone had any luck finding such a program or, failing that, can describe the process it takes in generating certificates? I have tried doing this via multiple methods without much luck (right now I'm getting ERROR 2026).
The code can be found here:
https://github.com/mysql/mysql-server/blob/5.7/client/mysql_ssl_rsa_setup.cc
How mysql_rsa_ssl_setup fits into the larger picture of enabling easier TLS connections is described here:
http://mysqlblog.fivefarmers.com/2015/04/09/ssltls-in-mysql-5-7/
The mysql_ssl_rsa_setup executable attempts to generate key material required for TLS connections to MySQL Server. It is typically invoked by package deployment scripts, rather than directly called by end users. It is part of the larger effort in MySQL Server 5.7 to enable TLS connections by default
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.