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).
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.
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.
Does MySql support for cluster environment? Whether Community edition support for clustering?
I want to know more details about it. Please guide me where can I get details?
You can read everything about MySQL Cluster (which is a different version than MySQL Community, but you can get both for free) on the MySQL website:
http://www.mysql.com/products/database/cluster/
MySQL Community edition can be set up to do master-slaves replication, but that's not as cool and effective as what MySQl Cluster can do.
Yes, MySQL Cluster does support clustering. If you have a Amazon EC2 account, I recommend this tool/website for setting up a MySQL Cluster quickly for testing: http://support.severalnines.com/entries/20916823-installing-on-amazon-ec2
MySQL Cluster is apparently the only MySQL solution right now from Oracle (outside of Percona and others) that allows for 99.999% availability (HA).
From my initial tests, MySQL Cluster is really fast at writes, but slightly slower at reads, though it aggressively caches reads after the first read. I'm still studying it myself.
Also, MySQL Cluster community edition should suffice for most use cases. I think the Carrier Grade edition is only for real heavy-duty uses.
You can get straight to the community (GPL) download for MySQL Cluster at http://dev.mysql.com/downloads/cluster/ (or the commercial version from Oracle e-Delivery - the functionality and underlying code base is the same).
An alternative to MySQL Cluster is SchoonerSQL, a cluster based on MySQL but uses the standard InnoDB storage engine rather than NDB. It supports 99.999% availability and has a very simple GUI management console. Go to SchoonerInfoTechcom
As most of you know, Sun acquired MySQL (and later Oracle acquired Sun), and during these acquisitions, there were a lot of FUD in MySQL community which resulted in creation of various forks.
Today we have MySQL from MySQL, Percona (XtraDB) MySQL, OurDelta MySQL, MariaDB, Drizzle to name a few. Which brings us to the source of the problem.
We are in the process of upgrading our databases (hardware/software) and I would like to know which one of the forks should I go with. Each has their own set of pros/cons. We are currently using MySQL 5.0.x from MySQL/Linux on an 8-core machine. Our new hardware is a monster with 32 cores and 32GB of memory connecting to a fast NetApp Storage via FC.
I would like to stick with MySQL from MySQL but I have heard horror stories on how badly MySQL 5.1 performs on many cores. I have also heard that MySQL 5.4 performs better on multi-core machines but that's still not production ready. In addition, I have also heard a lot of good things about Percona builds.
This is what I know so far:
MySQL 5.1 from MySQL: Reliable choice, but doesn't scale well on a big machine
Percona: Scales well, good backing company. I don't have much experience with it
MariaDB: Don't know much about it besides that it was founded by Original MySQL developers (including Monty)
OurDelta: Don't know much
Drizzle: Mostly optimized for cloud computing
I would like to know what's the general notion about this problem. Which build/version should I go with? How are you guys picking your builds/versions?
Thanks!
All of the 'forks' you mentioned (except Drizzle) re-base off newer official releases of MySQL. I think that the word fork can lead you down the wrong path - since the intention is just to provide after market modifications. I wrote about this here:
http://mtocker.livejournal.com/50931.html
Since they re-base of MySQL, and MySQL 5.0 is in "extended maintenance", only major vulnerabilities are to be fixed. This means you want to be moving to 5.1. If we work with this assumption, then it cuts OurDelta out from your decisions - since they are just the 5.1 MariaDB build/packaging partners.
I think you can also rule out Drizzle, since it is currently pre-beta. They're planning a beta by the end of the summer - but it's still much earlier than what you'll want. I really don't think you use a database not ready for production, so this rules out MySQL 5.5 as well.
So this leaves Percona Server, Official MySQL 5.1 and MariaDB. It's true that 5.1 has some poor scalability with many cores, but if you enable the InnoDB plugin it is better.
The rest of my response from here on in is biased - I work for Percona:
Percona XtraDB has additional CPU scalability fixes than MySQL 5.1+InnoDB plugin. The ones that are going to matter are covered here:
http://www.percona.com/docs/wiki/percona-xtradb:features:start
One I can comment on in particular that will matter is this one:
http://www.percona.com/docs/wiki/percona-xtradb:patch:innodb_split_buf_pool_mutex
Personally, I think that everyone who needs to set up a new MySQL installation today should be using MariaDB. MariaDB is based on the latest MySQL 5.1, actively maintained (including fixes for bugs reported against MySQL) and packages Percona XtraDB / InnoDB plugin.
I don't even know if "fork" accurately describes Maria, since they are committed to keeping up with current releases of MySQL.
In short: MariaDB 5.1 = MySQL 5.1 + Percona XtraDB + additional useful patches + active development and maintenance
Update late 2011- May 2012: I switched from MariaDB to Percona Server to get to MySQL 5.5 but I intend on switching back once the Maria team has a stable 5.5 based release. I think that everyone who needs to set up a new MySQL installation today should be running Percona Server. If you are using SSDs, you *must* run Percona Server.
2013-2018: Happily ran Percona server 5.6 this whole time.
2018: upgraded to Percona server 5.7 and then almost immediately to MySQL 8.0. [ At this point, I am not knowledgable enough to talk about the differences between MySQL 8, Percona Server 5.7 and MariaDB 10 and I can't say why you might want to choose one over the others ]
Use MariaDB. They've just released a version lately. Maria engine is also much better than MyISAM. With opensource project, you go where the founder go.
Just an update on this. We chose to go with Percona and we can't be happier. Percona guys definitely know their stuff and keep up with the new technologies. Just checkout http://www.mysqlperformanceblog.com/ Top notch software plus top notch people and great support, you can't go wrong.
I think it's still too early to write off MySQL entirely. I'm not enthusiastic about Sun/Oracle gaining the reins, but I don't have a clear idea what direction they'll take with it. Regardless, I'd wait another year before seriously thinking of switching to a fork. Time will tell which project has the resources and motivation to survive, or if a fork is even necessary.
Google has a memory library patch out that supposedly improves performance on multi-thread / core mysql installations. Supposedly, the performance bottleneck was in the memory allocation routines, and would manifest itself starting at 4 cores. I'm currently running a dual proc box with 4 cores each, and am having no problems with 5.1.x without the memory library patch.
My biggest suggestion to you would be to install 5.4 and run a benchmark suite against it. If it does the job, go with it. The fragmentation of the various forks does suck, but maybe it will be for the best. At least the founders have money now to fund their own direction... I wouldn't take the advice to follow them blindly though... It took a lot of time and efffort to set up the mysql infrastructure initially, and while it wouldn't hurt to support the team that did it the first time, there is no guarantee they will succeed the second time. So... support them, but don't rely on them until you know you can rely on them.
If you're upgrading your databases anyway, you should consider other FOSS DBMSes, or data management software systems as well, not just MySQL.
For example, if your DB workload is analytics more than transactions, and data is mostly added in batches, you should consider using MonetDB, a columnar DBMSes which is about 1.5-2 orders of magnitude faster than MySQL when doing analytics-only.
Another option is PostgreSQL. It's more transaction-oriented - like MySQL; in fact, they're similar enough to be proper competitors. There are arguments for preferring PostgreSQL and arguments for preferring a MySQL variant.
On DB-engines.com you can find other potentially-relevant DBMSes, FOSS and closed-source/commercial.