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."
Related
I have a java / spring / hibernate app running with connections to a MySQL db.
We recently upgraded from 5.6 to 5.7 (on a Windows server) and the app has gone from taking 3 hours to 3 days to complete. It essentially uses hibernate connections to retrieve read only data from the db before processing it and dumping the result elsewhere.
However as a first step, partly to check it was the upgraded version that is causing the problem, I installed 5.7.21 on my dev machine. I then noticed that even doing a db restore took several hours rather than what used to take about 10 minutes on 5.6. This has lead me to believe it may be more of a config issue than 'drivers' being out of date (I did think my first step was going to be upgrading app dependencies). I didn't install the server but I installed my dev machine with a default 'developer' install. Both the server and the dev machine are 64 bit Windows.
I've had a scoot around for obvious gotchas and not found anything yet. I just wondered if anyone could point me in the right direction before I start seriously thrashing about ? I have a good basic understanding of out of the box MySQL but I haven't done much config so even pointers to likely suspects in my.ini and best ways to investigate would be helpful.
When upgrading, pay attention to innodb_buffer_pool_size variable value.
It controls how much memory MySQL uses to make I/O operations faster. Usually, this is the one that makes it fly or that makes it crawl like a snail. There's a lot to be written about this particular variable, there's a plethora of excellent blog posts about it so I'll avoid explaining it into detail.
To see the current value, type in MySQL terminal:
SHOW VARIABLES LIKE '%innodb_buffer_pool%';
Change the value in config file and restart MySQL.
For the value, don't go overboard, don't exceed your entire RAM. You want it as high as possible, especially for servers with a lot of data.
We are getting ready to upgrade a fairly large MySQL 5.5 database to 5.6.35. The upgrade notes indicate an "incompatibility issue" associated with changes to the time/datetime/timestamp structures.
We know it's possible to run alter table ... force to upgrade the affected tables after upgrading to 5.6. However, given the size of this database we've confirmed it will take literally days to complete.
We can't use the online DDL feature [1] because according to the docs the time/datetime/timestamp alter won't work with the INPLACE algorithm.
We've also read that running a 5.5 DB on 5.6 will cause problems when replication to a 5.6 slave, which we need to do. But we can't confirm this issue without running an actual test.
Thus my question: are we required to alter the tables? We don't need the 5.6 microsecond feature, and never will. Can we just upgrade to 5.6 and be done with it provided we don't need the microsecond feature?
Thank you
Jason
[1] https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.html
We determined it is indeed possible to run a 5.6 replication slave in conjunction with a 5.5 master. The alter table ... force is not necessary either.
I am designing a data replication solution across timezones and have run into the issue where I can only run and old version of MySQL (5.6) in one location, whereas the other two have MariaDB 10.2.
Now, I have read the information about Replication Compatibility over at MariaDB. Clearly I can't use MariaDB as a master and MySQL as a slave.
Intermediate solution based on Bash scripts
Yet, I want to use my EU server as a master and that is running MariaDB. So I'm now contemplating a way around the limitation. So far I have come up with an intermediate data storage solution in the overseas server, where data is shuffled periodically using my own Bash data migration scripts over a low bandwidth link.
MariaDB is required in the primary location
I have to use MariaDB in my primary location because I'm using the ColumnStore database there. That is unconditional as part of the application design.
Does this situation ring a bell?
Do you have experience with similar situations and would you mind sharing some inspiration as for how you did it?
My best solution so far is with Bash scripts that are cronned, where MySQL data is dumped (mysqldump) and transferred over a low bandwidth link, then merged with the master (ColumnStore storage engine). I'm looking at a T+1 data lag between my primary location and the secondary location that is running MySQL.
Any high level design thoughts or shared experience is highly appreciated.
Best regards
I've just setup MariaDB on Ubuntu VMs with Master-Master replication using a combination of these three guides:
http://www.chriscouture.com/setting-up-replication-on-mariadb/
https://www.server-world.info/en/note?os=Ubuntu_16.04&p=mariadb&f=3
https://www.digitalocean.com/community/tutorials/how-to-set-up-mysql-master-master-replication
In short, both are masters and both are slaves to the other one. This will be used by separate web hosting servers. One will be "primary master" which all web servers connect to, and in case of a failure on that server they will be manually changed to the "secondary master".
The reason I went for this instead of Master-Slave is
The 3rd party backup job is simpler. Both backups and restores are done on the "secondary" master, instead of backup from the secondary and restoring to the primary.
If the primary fails and I have to switch to the secondary for a while, all changes made during that time should be written to the primary when it comes online again (?).
It's not live yet but everything works fine so far when I'm testing it. However I'm no DBA. I've been reading about how it's not "worth it" and if you don't absolutely need the Master-Master you should go with Master-Slave.
Now I'm afraid I will run into problems like inconsistencies and other headaches.
A maximum of about 100 databases for mostly Wordpress installations will be hosted.
What are your thoughts on the matter? M-M or M-S?
If M-S, how do I "sync back" data changed if the Master goes down and the Slave need to be the active server for a period of time?
I'm also wondering if there's a standard, generally accepted, step-by-step way to upgrade these. I'm thinking when a OS or MariaDB version upgrade is needed.
My general thoughts are something like take down one server, upgrade it, start it. Then take down the other, upgrade it, start it.
But I'm guessing there's more to it than that.
I only found some documentation on M-S upgrading with Mysql.
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.