1.MySQL5.6 的代码库的文件结构已经被改动了。比如单个代码文件已经被分成多个,又或者是某些代码已经被重新归类到了不同的文件内。所以要把MariaDB 去配合现在这个文件结构一定是一个非常消耗时间的过程。而其实我确实不是很明白MySQL为什么要改动现有的文件结构。
2. MairaDB 5.5 已经有大量的代码不同于MySQL 5.5 的版本,而且也有很多的新的特征被整合到MariaDB 5.5 中,而这些特征直到 5.6 版本才出现在MySQL中。所以我们在比较同样功能的MySQL 和MariaDB的版本,同时在完成设计和QA方面的审核后,一个很明显的结论是MariaDB会是一个更好的产品。在大多数情况下,在选择MariaDB的时候,人们会更多的考虑到功能方面的偏好。
3. 所以MySQL的新代码,至少是修改bug的代码以后都没有必要进行相应的测试了。我们试想一下,当有这样一个功能要加入到一段代码中,而这个功能原本就是来源于这段代码的情况下,测试将是一个异常重要的过程来保证这个功能的正常运行。
要 mysql 迁移到 maria db
在oracle收购了sun公司之后, mysql很不幸的落在了oracle的手中,mysql与oracle db存在竞争关系,很可能导致oracle公司影响mysql的开发与开放。mysql之父widenius在意识到oracle会对mysql做动作之前对mysql另开了一个branch:mariadb。作为一个能够完全兼容mysql的开源开放产品(向下兼容),受到了很多公司的青睐,red hat fedora ,opensuse ,维基百科,谷歌,淘宝等公司都先后把mysqldb迁移到maria db,从而更好的应对未来。
当然,未来还未来,如果mariadb的价值仅仅在未来,或许没有那么多公司愿意承担风险,进行数据库的迁移,特别是谷歌这样实力雄厚的科技公司,更不会担心技术不可控性。
可见,哪怕是现在,maria比之mysql也有很多的优势:
性能提升
2. 安全透明。(完全开源,开放,mariadb的商标属于maria基金会,以保障mariadb不会再次发生mysql这种事儿
3. 支持更多存储引擎。(nosql backend :cassandra )
4. mariadb galera cluster
同步复制真正的multi-master,即所有节点可以同时读写数据库。
自动的节点成员控制,失效节点自动被清除。
新节点加入数据自动复制;真正的并行复制,行级。
用户可以直接连接集群,使用感受上与mysql完全一致。
优势:
因为是多主,所以不存在slavelag(延迟);
不存在丢失事务的情况;同时具有读和写的扩展能力;
更小的客户端延迟;
节点间数据是同步的,而master/slave模式是异步的,不同slave上的binlog可能是不同的。
5. 与mysql完全兼容(至少是现在)。
风险评估。这是最现实的问题,如果数据迁移风险过大,或者迁移之后发现maria db上各种不适,将会对产品造成极大的伤害。值得庆幸的是,从maria db的官方blog上,我们看到mysql可以无缝迁移到maria的文章,还有mysql 与maria混用的相关实例。集群方面,maria采用的 galera cluster同样适用于mysql,应该不会有接入的风险。
当然,还有一个因素,就是尽早迁移会尽量降低复杂度,maria db与mysql未来肯定分道扬镳,兼容性会越来越差。
用户登录
还没有账号?立即注册
用户注册
投稿取消
文章分类: |
|
还能输入300字
上传中....