I'm using a rather busy MySQL 5.0 database. What are the main reasons for me to migrate to MySQL 5.1? Does it worth the trouble?
I use VS2008/.NET 3.5
Servers run as a MySQL cluster on Windows 2008 servers.
Thank you for your answers so far. To be more specific - I'm looking for answers such as the one by Quanssnoi, listing the features most important to him, rather than links to MySQL feature lists, which I of course read. Thanks.
Top reasons for me would be partitioning and XPath support.
For me the most important new feature was row-based replication.
Here's a list of new features in MySQL 5.1: What's New in MySQL 5.1 If you're not going to take advantage of these new features, and you have a production system running on MySQL 5.0, then moving to MySQL 5.1 might not be worth the trouble.
MySQL 6.0 (which is still in Alpha stage), on the other hand, brings a slew of new features including utf16 and utf32 support, and a new storage engine called Falcon.
I've noticed that DB dumps and loading of dumps works much better in 5.1 (5.0 has issues with those backwards compatibility comments). Notice I'm not referring to schema Backup, but dumps (different things).
Related
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)
I searched alot to install python3.6 and django2.0.2 with MySql server, but I got nothing because django2.0.2 framework doesn't support MySqldb yet.
Django REST Framework does support MySQL engine.
Django supports MySQL 5.5 and higher.
Django’s inspectdb feature uses the information_schema database, which
contains detailed data on all database schemas.
Django expects the database to support Unicode (UTF-8 encoding) and
delegates to it the task of enforcing transactions and referential
integrity. It is important to be aware of the fact that the two latter
ones aren’t actually enforced by MySQL when using the MyISAM storage
engine, see the next section.
Source: https://docs.djangoproject.com/en/2.0/ref/databases/
Follow the link to setup the configuration
I am bit novice in some aspects here and no related information found...
I have an AWS instance with mysql client installed at 5.5 version. And also an RDS db instance with mysql 5.6 (in order to use t2.micro). I don't think so but, could this in your opinion/experience produce some kind of trouble when requesting queries (via PHP, specifically Symfony2) between them?
I hope it is no; but if yes, is strictly necessary then to upgrade my mysql client in the instance or there is any other way to use t2.micro with mysql server at 5.5?
Any guidance or related experience would be much appreciated.
See Upgrading from MySQL 5.5 to 5.6:
Note particularly any changes that are marked Known issue or
Incompatible change.
That said, your client app should be able to use 5.6 safely, and you got it right, that is required to use db.t2.micro instances.
I'm trying to install Magento Community Edition for my latest project on our server, however, the hosting platform we are currently using doesn't, and won't let us, install or utilise InnoDB.
Is anyone aware of any configuration/changes that can be done to make it work any other way?
Magento was developed and is supposed to be used in a transaction-safe environment.
You could try switching to some other database which is transaction-safe (like Oracle), but then you'd need to write PDO adapters and resource models for Oracle by yourself (they're not part of Magento). But if your provider doesn't even support InnoDB, I don't believe he will support Oracle or similiar^^
Another possibility would be to make Magento able to work with a non-transactional mySQL engine like MyISAM. You'd need to rewrite many processes, core models and controllers to change Magento from transactional to non-transactional behaviour.
Not only would this be tons of work, but I'm almost sure, you would get a lot of fun each time you try to upgrade your Magento version. I'd strongly encourage to never change the core this way.
The only mySQL engines supporting transactions are InnoDB and NDB. Magento only ships resource models for InnoDB. So, if you ask me, if your provider doesn't allow InnoDB for whatever reasons, I'd recommend to just move on to another provider that does.
I was trying to install Magento 1.9 CE on my own development server. Eventually the Magento Downloader incorrectly stated that InnoDB is not the default database engine. This was the issue I had when installing Magento CE.
Yes, it is true that MariaDB, a binary compatible replacement for MySQL uses xtradb rather than innodb as its engine.
https://mariadb.com/kb/en/mariadb/xtradb-and-innodb/
However, I am tempted to conclude the problem lies in Magento:
Magento install complains about missing InnoDB when it is available
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