galera

1.mariadb主从 主从多用于网站架构，因为主从的同步机制是异步的，数据的同步有一定延迟，也就是说有可能会造成数据的丢失，但是性能比较好，因此网站大多数用的是主从架构的数据库，读写分离必须基于主从架构来搭建。 主可以将数据同步到从上，但是从不能将数据同步到主上。 二进制日志这能一条一条的写入，因此数据的同步会有延迟。 异步优点：性能好，效率高 缺点：数据的安全性低 同步优点：数据的安全性高 缺点：效率低 mariadb的复制过程： 1.master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）； 2.slave会生成I/O线程和SQL线程，I/O线程会读取master的二进制日志，master会生成一个dump线程将数据返回给slave端，存储到slave的中继日志(relay log)中。 3.slave端的SQL thread（SQL从线程）处理该过程的最后一步。SQL线程从中继日志读取事件，并重放其中的事件而更新slave的数据，使其与master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。 面试会问到的 如果slave有多个，那么master端会生成许多的dump线程，这对于master端会造成很大的压力，为了解决这种问题我们可以这样解决：

环境： 192.168.205.37: as member of galera-server 192.168.205.47: as member of galera-server 192.168.205.57: as member of galera-server 版本： OS: centos 7 1810 with mini install mariadb-server 5.5.64 目地： 集成了Galera插件的MySQL集群，是一种新型的，数据不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分别是Percona Xtradb Cluster及MariaDB Cluster，Galera本身是具有多主特性的，即采用multi-master的集群架构，是一个既稳健，又在数据一致性、完整性及高性能方面有出色表现的高可用解决方案。 Galera要求至少三个节点组成集群，与普通的主从架构不同，它们都可以作为主节点，三个节点是对等的，称为multi-master架构，当有客户端要写入或者读取数据时，连接哪个实例都是一样的，读到的数据是相同的，写入某一个节点之后，集群自己会将新数据同步到其它节点上面，这种架构不共享任何数据，是一种高冗余架构。 步骤 准备yum 源，此包与mariadb-server冲突，必须不能安装mariadb-server

MySQL集群 MySQL高可用 MMM: Multi-Master Replication Manager for MySQL，Mysql主主复制管理器是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)   官网： http://www.mysql-mmm.org    https://code.google.com/archive/p/mysql-master-master/downloads MHA： Master High Availability，对主节点进行监控，可实现自动故障转移至其它从节点；通过提升某一从节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，出于机器成本的考虑，淘宝进行了改造，目前淘宝TMHA已经支持一主一从   官网: https://code.google.com/archive/p/mysql-master-ha/ Galera Cluster：wsrep(MySQL extended with the Write Set

各位老铁们，你们有没有想老张，最近老张的才华被工作的繁忙所限制了，所以一直没时间更博，今儿个时隔数日我们终于再次见面啦（很开心）！最近有部特别火的宫廷戏，不知道大家有没有看，剧名叫做《延禧攻略》，讲述得是一个宫女，一路过关斩将，最后成为皇上最宠爱的令贵妃的故事。加上我本人巨爱这类题材，所以痴迷得不得了。（好像暴露了自己没有更博的真正原因哈哈）。宫廷类的剧，都是后宫嫔妃之间的尔虞吾诈，勾心斗角，有你没我，有我没你的残酷事实。胜者为王，败者为寇这种思想好像从古代就一直延续到今日。非要分出个胜负，分出个谁好，谁坏才罢休。 在数据库领域也会有此类问题，老张我混迹开源数据库圈多年。MySQL数据库占领着开源数据库的头把交椅，MongoDB占领着NoSQL数据库的第一位。我们来看下数据库的整体排名情况； 两者都是第一，所有总会拿来比较。也会经常被人问及到诸如此类的问题MongoDB4.0已经问世了，而且支持事务了，是不是将来可以取代MySQL了。MySQL和MongoDB哪个数据库好用啊。今天老张想通过这篇文章，带着大家全方位解读MySQL与MongoDB的区别。让有困惑的老铁们明白，没有谁替代谁，只有哪个场景更适合谁。 我们从下面四个方向依次阐明两者的区别。只有更了解彼此，让能更好地利用它们的功能性。 第一部分：数据库概述 我们先来了解一下MySQL这个数据库；

参考文章： https://ieevee.com/tech/2018/05/16/k8s-rbd.html https://zhangchenchen.github.io/2017/11/17/kubernetes-integrate-with-ceph/ https://docs.openshift.com/container-platform/3.5/install_config/storage_examples/ceph_rbd_dynamic_example.html https://jimmysong.io/kubernetes-handbook/practice/using-ceph-for-persistent-storage.html 感谢以上作者提供的技术参考，这里我加以整理，分别实现了多主数据库集群和主从数据库结合Ceph RDB的实现方式。以下配置只为测试使用，不能做为生产配置。 K8S中存储的分类 在K8S的持久化存储中主要有以下几种分类： volume: 就是直接挂载在pod上的组件，k8s中所有的其他存储组件都是通过volume来跟pod直接联系的。volume有个type属性，type决定了挂载的存储是什么，常见的比如：emptyDir，hostPath，nfs，rbd，以及下文要说的persistentVolumeClaim等