有了自知之明才能做对的事情，得益于老客户的信赖和我们过去几年实践经验的积累，今天终于算是完成了一个大型任务。
前几天我们的客户遇到了一个大问题，因为具体细节有关隐私和安全防护，就不多介绍，主要是去年到今年我们给部署了五台 WordPress 多站点站群服务器的老客户突然全部网站系统发生异常，访问慢或者 502 错误、后台打不开，原因是这几台服务器都共用的一台 RDS 数据库服务器 （阿里云），也就是客户开启和创建的子站太多，每台机器差不多有 1~2000 个站，而且都是活动和动态更新的网站。
突然就出现了服务器无法正常访问或者很慢间歇性的故障，检查了下 RDS 数据库用量，发现纯数据库的大小已经超过了 100 多 GB ，而且 CPU 已经是 97% 以上，快要爆表了。
要解决此问题有两种方式，一种是升级阿里云的 RDS 数据库提高性能，另一种就是新购一台数据库服务器，然后将五个 WordPress 多站点站群的数据库给切割分离，这些操作并不是最麻烦的，真正的麻烦是阿里云对数据库做了一大堆的限制，连正常的数据表导出都没办法实现，每次只能导出 100 张表，但现在数据库里面有超过 8 万张数据表。
看了下阿里云的 RDS 企业版说明，升级后最多可以一次导出 10GB 的数据，这样的话也是很鸡肋，因为五个 WordPress 系统的数据库加起来是 100 多 GB ，这样的话即使一次导出 10 GB，也都得十次才能导出完，另外导出后还需要下载，再次上传。。。这么操作起来，起码得一周左右的时间跨度才能把这些数据处理完。
花了一个早上，我们制定了一个方案，确切的说是换了种思路，还是想办法从 WordPress 系统本身也就是 Web 程序端入手。
既然阿里云限制不允许进行大批量的操作，那么换种方式，我们直接从 WordPress 站群系统里先 「导出」 一个包含全部子站数据库表的完整备份不就行了。这样的话，我们只需迁移的旧服务器的数据库备份，然后再去新数据库里恢复。
操作步骤也公布下：
1 、进入 WordPress 多站点站群，导出全部子站的数据库，保留好备份 （A），再对全站的静态数据和系统文件进行备份；
2 、调配好新的数据库，然后删掉/修改 WordPress 多站点站群的配置文件，再用新库 （B） 的信息进行安装，也就是程序再全新部署一次；
3 、将备份数据库文件进行恢复处理，这样就可将旧站 （A） 的数据全部都恢复到新的数据库 （B），而且保留了原始文件和网站结构；
上面的三个步骤看上去很简单，但对于一个单就数据库超过 100 GB 的项目来说，并不容易，因为本身系统的资源就已经不够了，我们采取的策略是备份某一台服务器数据库的时候先对其他几台进行停机处理。
旧库备份成功后，再到新库 （B） 里面创建一个信息与旧库 （A） 一样的数据库，然后手动将站群程序再使用新的数据库信息部署一遍，这样就不再使用旧库 （A） 里面的数据表，但新库 （B） 里面目前还是空白的，后面通过 Web 端的 WordPress 程序恢复原先备份的旧库 （A），等待数据导入完成后，也就迁移搬家完成了。
经过反复测试了整整三天的时间 （白天晚上都在试），我们完成了对数据库的分离和迁移，也就是将其中的三台 WordPress 站群服务器给迁到了新库中，整体的数据量加起来差不多有 3000 多个站点，而原先的旧数据库也得以减负了几十 GB ，现在各个站点都已经恢复正常可用。
这是我们做的最大规模的一次数据迁移和数据库分离，五台服务器全部的子站加起来有 5000 多个 WordPress 站点，然后分离后成功迁移差不多 3000 多个 WordPress 站点。
除了我们对站群系统的性能优化外，WordPress 系统本身良好的数据结构和可扩展性也是不可忽视的因素。
总体来说，这个数据迁移订单处理的没那么轻松，但也不是很棘手，更重要的应该是此次的折腾操作让薇晓朵具备了处理 TB 级别 WordPress 大数据的能力 （1TB=1024GB），也对大型数据库的处理有了更深入了解。
同时这也为我们后续的 WordPress 多集群和多租户系统解决方案有了一次测试和实践的机会，未来我们想在一天之内就可以转移和迁移 10000 个 WordPress 网站，虽然现在一般站群客户都是只有开 2000~3000 个站的，但越往后发展，我们可以做和能做的事就会越多。
发表回复