Inventor's Paradox

I just recently upgraded a database server that were previously running MySQL 5.1 (standard, Sun/Oracle version) into Percona Server 5.7. A few quirks notable enough to warrant this blog post. Planning and Preparation A Percona blog post ( mysql-upgrade-best-practices ) stated that the best way to upgrade with such huge difference in major version (5.1 to 5.7) is to do a full logical dump for all database except mysql, dump user and grants, uninstall database and remove datafiles, then install new version and import the logical dump and grants. But alas the database we are going to upgrade is so big and the IO subsystem became some sort of bottleneck when doing logical dump, our colleagues tried to do mysqldump and it tooks more than 2 days to run, prompting us to cancel the backup (otherwise it would interfere with workday application usage of the database).  Reading the blog I noted that : for major version upgrade, using logical dump  and restore dump is the safe...

I am currently running OpenShift Origin  V3 platform on a CentOS/RHEL 6.5, but needs PHP 5.4 support. The problem is, PHP cartridge in v0.08 only supports the original PHP version that cames with the OS, which is PHP 5.3. Other people using Fedora might be able to use PHP 5.5 even with v0.08 version of the PHP cartridge. The steps to install Origin V4 cartridge (cartridge version 0.20 in manifest.yml / 1.26.9.1 in rpm spec) is (if you have no idea what these means, then you really shouldn't try them) : download the PHP cartridge from Origin V4 rpm repository erase the previous PHP cartridge using yum (yum erase ...) install the new PHP cartridge using rpm (rpm -i ....) install the new PHP cartridge using oo-admin-cartridge (oo-admin-cartridge -a install -s ...) restart the mcollective on the node server (service ruby193-mcollective restart) repeat these process on all nodes clear caches on broker server (/usr/sbin/oo-admin-broker-cache --console) However, as so...