I want to transfer my Ruby on Rails project to another platform.
Currently my RDS is running over mySQL 5.5 which is discontinued, will it be ok to utilize mySQL 5.7 instead and will database migration be affected?
What could be consequences?
Mysql does not support direct upgrade skipping versions, so you'll have to upgrade in steps: 5.5->5.6->5.7, and then, maybe, 8 (actually, sometimes for simple databases a 5.5->5.7 jump might work, but it is not guaranteed and you may loose data).
make a backup
You need to have compatible mysql2 gem version (fresh enough)
See MySQL changes(5.6 and 5.7) and corresponding upgrade guides to:
make your app compatible (replace deprecated/removed features, adapt for new defaults etc.)
migrate data and mysql itself (if your database is big or under constant load, logical dumping+loading might not be acceptable), usually it involves upgrading to most recent patch version and then jumping to next version, sometimes running mysql migration tool
plan for a downtime (in worst case - a backup restore)
To minimize downtime - you can make use of mysql's ability to create a mixed-version cluster (add 5.6 slave to your present 5.5 master, then promote in to master, and so on)
Related
I was looking into trying out Adempiere 380 LTS specifically with MySQL. Is there a seed database anywhere that I can use? There used to be one for 360 but I'm not sure if it's still compatible (probably not).
If not any suggestions on a work around. I've started a migration of a seed PostgreSQL to MySQL but the process is slow as it requires quite a bit of manual intervention from the looks of it.
There isn't one at the moment.
The latest MySQL dump, that I can see, is available here.
You would need to either successfully migrate latest PosgreSQL database over MySQL (there's something called pg2mysql, mysql workbench also has a migration tool) or try to adapt 360's MySQL dump to the latest version of Adempiere.
Whatever the option, there's going to be quite a bit of manual work to get it working 100%.
I am using the latest MySQL Chef recipe to install MySQL server. I want to create a database next. The database recipe specifies MySQL ~> 5.0.
How does one deal with those version dependencies? I can try to change the dependency for the database recipe and see whether it will still work, but that does not feel right.
What is considered best practice for that?
Its unclear if you're talking about mysql version or cookbook versions.
But I'll assume you're talking about cookbooks.
Database cookbook depends on mysql cookbook in version 5.0.x which may install mysql in version 5 to 5.6.
The mysql cookbook has been bump to 6 (major change), it means it has breaking changes with previous major version.
The database cookbook was not tested (or tested and failed) with mysql cookbook in V6.
For the global 'how to deal with that' the best answer in my point of view is to have a wrapper cookbook for your database which will depend on the database cookbook.
That will take care to install mysql and what is needed for your DB when you call your recipe (you may tweak mysql install by attributes in your wrapper cookbook and include specific recipes not in default path if you need them).
I think your main problem here is seeing the mysql install and the db creation as two separate things but in fact the mysql server install is just a prerequisite of your database creation.
I am doing a research regarding migrating from MySQL to MariaDB and viceversa.
As it seems, the first part should be easy and not complicated as stated here: MariaDB versus MySQL - Compatibility
It is the "viceversa" part that botters me: MariaDB -> MySQL. I just could not find anything useful about this topic.
Can anyone help? Any advice, hint? Are there complications migrating from MariaDB back to MySQL?
Thank you so much.
If there is someone who should ever take care of migrating from MariaDB to MySQL, it would be Oracle. As Oracle pretends MariaDB does not exist (company politics-policies) , it also does not provide the possibility to migrate (which does not bother me personally, because being on MariaDB team I'd prefer people to chose it and stay there :)
Having said all the above, the migration should be straightforward, provided you do not use special features (so, no storage engines besides MyISAM/Innodb). You shutdown MariaDB, you save the data directory, remove MariaDB, install MySQL, copy the saved data directory back. In the worst case you'd need to remove parameters from my.ini/my.cnf that are not recognized by MySQL.
The point I'm trying to make is since persistent data formats for most commonly used storage engines are compatible, no data migration is required (at least not yet:)
It's very easy ton migrate Mysql to MariaDB (so, no storage engines besides MyISAM/Innodb).
Backup your database
Stop mysql server
Set your repositorie
(http://downloads.mariadb.org/mariadb/repositories/), it's depend on your linux stack.
Execute commande line to install MariaDB.
But now migrate MariaDB to Mysql is more difficult. I have no solution yet for this operation. Since my last try i have crashed my server...
I would like to replace MySQL 5.1 on my Debian Lenny 32-bit server to Percona Server with XtraDB. The main reason is better performance of Percona.
It's production server with many services running. Many other software may depend on mysql-client and other mysql shared libraries.
Is it safe to replace MySQL?
By "safe" I mean: 1. remove mysql, 2. install percona 3. everything works as before
Will it break dependencies in third party software?
Will it require to change configuration of third party software (ie. socket path, server port, shared libraries path)?
Will it require to install trillion of additional packages?
I really don't want situation with broken libraries, missing or incompatible header files and so on
We are currently in the process of upgrading from MySQL 4.1 to Percona Server 5.5 at work and Percona is as they say on their site a complete drop-in replacement for MySQL, the binaries use the same names, it uses the same libraries, same config file placement, takes the same parameters and it has exactly the same SQL syntax. They should also be data file compatible on the same version (MySQL 5.1 to Percona 5.1, etc) but it's nothing I've personally verified.
You are able to do an apt-get install percona-server-server-5.1 after adding their repositiories and it will automatically replace MySQL because it marks it as a conflicting package. But you must take an SQL dump of your database first, of course.
We currently have replication set up from a MySQL 4.1 master to a couple of Percona 5.5 slaves and have had no problems inserting SQL dumps either.
... don't know.
In my experience, the only way is to make up a copy of your existing setup on an old machine and run some tests. Then swap over to the new DB and run same tests again.
I just swapped a set of applications from Tomcat 5 to Tomcat 6 and in theory, with one or two tweaks, all should have worked fine. First time I tried it OpenJava was installed and the garbage collection fouled things up. Second time around with Sun Java, some dodgy date handling fouled things up and had to be corrected, seems to run fine now.
In Mysql Administrator, when doing backups, what exactly is "Compatibility Mode"?
I'm trying to bridge backups generated by webmin with the upload tool available inside mysql administrator. My data already has a couple of inconsistencies (ticks, commas, etc, I think) I just wont try to kink out (they might just reappear in the future anyways). These kinks generate errors when I try to restore out of my backups.
Now, if I generate backups from webmin, and then use MySQL administrator to restore them, they fail. But if I generate the backups using MySQL Administrator AND tick "Compatibility Mode", then head over to MySQL administrator (another instance) and restore... it works!
According to MySQL, "Compatibility Mode" is;
Compatibility mode creates backup files that are compatible with older versions of MySQL Administrator.
Webmin, on the other hand, gives me the following options for compatibility:
ANSI
MySQL 3.2.3
MySQL 4.0
PostgreSQL
Oracle
Microsoft SQL
DB2
MaxDB
Which would you say is a best fit? My data set is very large, so it would take quite some time to experiment one by one (specially whence thinking might beat brute-forcing it).
Edit: seems like it's doing ANSI, but i'm not 100% on it.
Compatibility mode - the mode that helps you create exports compabible with different versions of MYSQL or other databases.
You see, some versions of MySQL had different commands that were used in various versions. So what compatibility mode allows you to do is take a database and export the SQL to be compatible with another version of MySQL. Thus, you may want to upgrade your MySQL 3 server to 4 - this compatibility mode allows for the export your database or individual tables to create a SQL file that can import into a MySQL 4 version server (should work in 5 also).
I use webmin, also, and run MySQL 5. I use compatibility mode for MySQL 4.... I steer clear of any of the other ones, because I'm not running those other databases.
As far as the MySQL commands that were different between MySQL 3.x and 4.x, I believe there were changes in regards to how CURRENT_TIMESTAMP is translated from MySQL 3 to 4, and also MySQL 3 doesn't support charsets, according to this forum post here: http://www.phpbuilder.com/board/showthread.php?t=10330692