Migrating from MySQL to MariaDB and viceversa - mysql

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...

Related

Will mysql version change affect migration?

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)

Is there a MySQL seed database dump for Adempiere ERP 380

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%.

Can I use the MySQL books I already have to learn MariaDB?

Ultimately, I want to learn MariaDB. I’ve found that there are hundreds more resources for learning MySQL than for MariaDB. My assumption is that everything I learn from a MySQL book will also apply to MariaDB since it’s a drop-in replacement for MySQL.
From the MariaDB website:
For all practical purposes, MariaDB is a binary drop in replacement of the same MySQL version (for example MySQL 5.1 -> MariaDB 5.1, MariaDB 5.2 & MariaDB 5.3 are compatible. MySQL 5.5 will be compatible with MariaDB 5.5).
Will I be able to use MySQL books to prepare for learning MariaDB or will they be useless to me if what I really want to learn is MariaDB?
If you take care about the few differences and incompatibilities (very few, mariadb starts from the same codebase than MySQL), you should have no problem using a resources from one DB and applying them to the other DB.
Even more so if you are mostly focusing in SQL syntax.
You don't really need to care about the differences, unless you are a very advanced user. MariaDB can replace MySQL with every application I know. Some MySQL 5.6 optimizations are not in MariaDB, but much more MariaDB optimizations are not in MySQL.

Can I use MySQL Workbench to create MariaDB?

I am totally new to databases. I would like to create a database; I am going to make a small project which is going to use DB. I am going to use Maria DB as it is totally free for commercial use.
The question is: Can I use MySQL workbench program to create a database and then transform/change it to MariaDB?
From my experience -- Sure, you can use MySQL Workbench with MariaDB.
However, I have tried basic functionalities only, like queries, schema design etc. Not sure about compatibility of advanced features.
So my experiences are, yes you can use MySQL Workbench for MariaDB database designs.
However I needed to change the "Default Target MySQL Version" to 5.7.
This can be done by going to: Edit->Preferences in the menu. And finally to Modeling->MySQL.
Since the latest MySQL version, v8.x, the SQL statements are not compatible with MariaDB statements (like creating an index). MariabDB creating an index on a table:
INDEX `fk_rsg_sub_level_rsg_top_level1_idx` (`rgs_top_level_id` ASC)
vs
MySQL:
INDEX `fk_rsg_sub_level_rsg_top_level1_idx` (`rgs_top_level_id` ASC) VISIBLE
MariaDB can't handle this VISIBLE keyword in this example. Using an old MySQL Version, MySQL Workbench will forward engineer a compatible MariaDB SQL file.
Currently (Oct 2019) the generated SQL_MODE output is still compatible with MariaDB. Just like InnoDB, which is also preferred when using MariaDB in most cases.
Just to list a few other options:
MySQL Workbench
Heidi Sql
SQLyog
No.
The latest version of Workbench 8.0 is not supported in MySQL.
Yes, although connecting to view existing database on a remote MariaDB server will crash the current client (6.3.10). I use it mainly to deploy database models and that works fine, even on remote servers.
I just deployed to a MariaDB 10.3 server with that client and it worked fine, see screenshot.

Migration from SQL Server to MySQL

I need to migrate data from SQL Server 2000 to MySQL. Currently I am using MySQL workbench. Can any one tell how to do this?
If you are searching for a tool MySQL has a tool called "MySQL Migration Toolkit" that can be used to migrate the data from SQL to mysql. But the first thing as mentioned above is to do a backup. The next thing to check would be whether there are any datatypes that cannot be converted?
Exactly, what have you tried? You can quickly migrate data from MSSQL to MySQL if they are in any of the following data file formats:
Paradox (.db)
DBase (.dbf)
Delimited Text (.txt)
Excel (.xls)
XML (.xml)
MS Access Database (.mdb)
ODBC
If its a one-to-one, exact same database architecture on both the new and the old servers, you might want to try using database tools meant to make this an easier process for GUI based administrators. Just go to download.com and find some software that may assist you in that migration, Navicat is a good one. The most important thing is to always BACK IT UP! BACK IT UP! BACK IT UP! Never do anything without mirroring drives and doing whatever it takes to make sure if you don't destroy any data, but if you do you'll have backup copies of it. Also how fast your machines are will be a sizable factor when it comes to migrating very large databases.
All in all you have many options to choose from, yet the most important thing is to back it up! Can't stress that enough, yeah it might seem like meaningless extra work especially on humongous database systems, but trust me, its better to be safe than sorry. Also, I always like rebooting machines prior to making database changes to them, cutting off any connection to the outside world or any processes depending or updating its data. Turning off the ODBC will do much of that for you on Windows as well, but as always better safe than sorry. Many a corruption can be avoided by simply booting the machine and having all data in memory finalized on the active database, before backing it up or appending to it.
Check out etlalchemy. It is a free, open-sourced Python tool capable of migrating between any of the following SQL databases: PostgreSQL, MySQL, Oracle, SQL Server, and SQLite.
To install: pip install etlalchemy
To run:
from etlalchemy import ETLAlchemySource, ETLAlchemyTarget
# Migrate from SQL Server onto MySQL
src = ETLAlchemySource("mssql+pyodbc://user:passwd#DSN_NAME")
tgt = ETLAlchemyTarget("mysql://user:passwd#hostname/dbname",
drop_database=True)
tgt.addSource(src)
tgt.migrate()