摘要
每次“折腾”其实都是有不少收获的，比如这次的折腾虽然以失败告终，但是至少也算是体验了一番Upgrade MySQL to MariaDB的过程，对MariaDB也算是有了一个初步的认识了。有条件还是要尽早将MySQL替换为MariaDB最好，至于说数据的导入、导出完全不用担心“转换”的，它们之间的兼容性那真的是“刚刚的”，毕竟是出自同一个创始人之手的开源数据库嘛！
其实这次升级 MySQL 是个很偶然的决定，主要就是看到了 wooCommerce 插件升级的时候联想到了最近总是发现在使用了 wooCommerce 插件后数据库总有不正常错误出现，从 wooCommerce 插件的支持情况来看可能是因为 MySQL 版本低于 5.6 造成的，所以就想升级 MySQL 的打算了，受制于服务器只有 1G 内存一直没有实现，还以为 MariaDB 对内存没有这个要求呢！
想到就要行动起来，因为使用的是军哥的 LNMP1.5 测试版，在 upgrade.sh 脚本里就自带了 Upgrade MySQL to MariaDB 的选项，就直接用脚本升级了，数据库太大了，编译安装耗时近一个多小时。结果是彻底失败，MariaDB 里竟然没有任何数据表，PhpMyAdmin 里也是彻底乱了套，界面错位，无法正常操作。折腾了两个多小时才发现是 ngx_lua_waf 拦截造成的，无奈暂时关闭 WAF。这时候站点已经都无法访问了。没有办法只能请出阿里云的镜像回滚恢复了。
恢复正常后还是不甘心呀！所以继续努力继续折腾，这次提前把数据库都导出来以备不时之需，关闭 WAF 防火墙重新来过，近一个小时的等待后终于成功了，这次很完美，数据表依然是丢失的，还好编译前有备份，立马导入数据，又发现 MariaDB 的 root 密码竟然无效了，只能重置数据库密码了。终于恢复网站访问了！么么哒！！！
等等，有点儿不对劲儿，服务器控制台终端好卡的感觉，一看负载，我去一直在“飙升”直至网站打开出现 503 错误，负载还在持续飙升一路到 50 多了！我去，这也太猛了吧！难道是因为 MariaDB 没有优化所致？于是又对 MariaDB 的配置文件进行了一番研究调整了一些参数优化了一番，重新载入 MariaDB 后，CPU 的负载依然是 90%以上，这时候突然想起来 MySQL 5.6 以后的版本对服务器内存有要求至少是 2G 以上，难道 MariaDB 也有这个要求，MariaDB 的版本我选的是 10.2.12 版，百度、谷姐一番后基本上可以确定就是服务器物理内存太小造成的了！哎，无语了，看来升级到 MariaDB 也是没有办法的，只能是镜像回滚恢复了。
至此，这次 Upgrade MySQL to MariaDB 的折腾还是以失败而告终了，服务器配置太低是主要原因，虽然 MariaDB 那么的诱人，但至少目前来看是无福消受了！我说为啥阿里云 ECS 1G1 核的卖的这么便宜，原来又是“套路”呀！唉，真的是彻底的服了！
不过，每次“折腾”其实都是有不少收获的，比如这次的折腾虽然以失败告终，但是至少也算是体验了一番 Upgrade MySQL to MariaDB 的过程，对 MariaDB 也算是有了一个初步的认识了。有条件还是要尽早将 MySQL 替换为 MariaDB 最好，至于说数据的导入、导出完全不用担心“转换”的，它们之间的兼容性那真的是“刚刚的”，毕竟是出自同一个创始人之手的开源数据库嘛！