一、mysql主从架构原理
1.主从架构业务背景
为了解决性能问题（数据库资源访问、数据库连接不够），要将原来的一个数据库结点扩充为多个（提高承载性）。结点由一变多，前提是多个结点里的数据必须是一模一样的。
通过mysql主从架构的方案，有master主结点和slaver从节点，主节点将数据同步到从结点去，并且这种同步是自动的、可靠的。解决了每个结点数据一模一样的问题。
2.主从同步实现（异步）
应用程序访问master主结点数据库，进行增删改操作，将数据写到主库的硬盘中去，同时把sql语句作为日志记录到binlog文件中。从节点有两个线程：io线程（io thread）和sql线程（sql thread）。io线程会连接主节点，并且从binlog文件中取出相关的sq语句，存储到从结点的中转binlog日志（relay binlog）中。sql线程会从中转binlog中拿出sql语句， 再在data库里执行，存到硬盘中。
从节点不仅有中转binlog日志（从主结点去过来的sql语句），也有binlog日志（执行的sql语句（增删改）的日志），因为（1）从结点可能也有自己的从节点，就需要从自己者复制binlog。（2）数据误删之后可以恢复。
3.主从架构优缺点
优点：提高性能、承载性
坏处：出现数据主从不一致情况（同步过程中网络断了，数据保存在主库，但没有同步到从库中）、数据同步延迟（在主库中刚写完就查，而从库还没同步好，出现查询的数据不一致）
避免数据主从不一致问题：
采用半同步避免。
之前那个是异步的：就是应用程序往主节点写好数据，就直接返回了，不管从节点有没有同步好。这种异步的方式保证操作的性能不会受到同步过程的影响。半同步是当应用程序往主节点写好数据后，会wait阻塞住，直到从结点将sql语句同步到自己的中转binlog中，才会向应用程序返回。（叫半同步是因为只是同步到relay binlog中，并没有完全将数据同步到从数据库的硬盘中，还需sql线程去执行）
半同步会在一定程度上影响写入的性能，解决办法：设置一个同步的超时时间，比如2秒钟。
（数据高一致性（半同步）和高性能（异步）之间要平衡）
数据同步延迟问题的解决：（1）从库中的io线程和sql线程多加几条，加快同步速度。（2）对于写完之后要读的，强制它读主库，不让读从库（从库同步慢）
4.主从架构的作用
（1）提高承载性，提高性能
（2）实时灾备
（3）用于故障切换
（4）读写分离负载均衡
（5）业务隔离
5.msql主从架构方案
方案有：一主一从、一主多从、（后面不常用）双主、级联同步、环形多主。
（1）一主一从
90%的企业都在用这种。
原理：往master中写，会自动同步到slave中去。程序所有的读写都在master中，slave只是个备份（不会提高承载能力）。当master挂掉后，程序会连到slave（高可用）。---->相当于双机热备。
slave只是master的备份，不能做为数据的备份。因为master删除的数据，slave也会被删除，slave不能恢复一天前的数据，因此master要每天做个增量或者全量的备份。
这个方案不会存在主从数据不一致问题和延时问题。
（2）一主多从
能够瞬间提高程序性能和承载性能的解决方案。大部分公司采用读写分离所采用的方案。
原理：master结点承载所有的写请求，然后同步到各个从节点。从节点承载大部分的读请求。在从节点中还有一个特殊的备份结点，去执行一些耗时操作，比如数据统计报表、定时任务、专门给程序员查询线下生产环境数据等。此外，从节点中还有一个特殊的结点，作为master的备份，当master挂掉后，就会替代master结点。
（3）双主
当写入压力非常大时，会采用双主。两个结点都会承担读写请求。各自互相同步。因此各自的id不能冲突。根据id取模，一边奇数一边偶数。
（4）级联同步
好处：如果master结点挂掉，从节点是个天然的主从架构。
风险：中间结点挂掉，从结点就丢了。
（5）环形多主
一般不用
二、基于docker构建集群结点
用docker实现一主多从
docker是虚拟容器技术。相比虚拟机消耗的性能更少，启动速度更快。
docker有三部分：
docker客户端：输入docker命令。
docker主机：有多个容器和镜像。每个容器是隔离的。容器需要镜像去启动。所有本地要有个镜像仓库，仓库里存放静态的镜像文件（redis、ubantu等）。一个镜像可以附着于多个容器进行启动。镜像相当于class类，而容器相当于对象object。容器间互相隔离，但实际还是都运行在虚拟主机上，只是不同的进程。镜像文件可以自己构建，也可以远程下载。
docker远端仓库
命令：
docker search 镜像名 #搜搜远端的镜像
docker pull 镜像名 #拉取远端的镜像
docker run 镜像名 #运行本地镜像，没有就从远端拉取再运行
docker compose是做编排的，把所有相关的docker程序都编排到一个系统去，做到一键启动、下载、关闭等，非常方便。就实现把多个docker容器放到一起运行的效果。原则上一个docker容器只守护一个进程（比如一个容器redis、一个容器nigix）。因此docker compose就管理这多个容器。
容器中不推荐存储频繁数据读写的文件（动态文件），因为docker文件系统是虚拟化的，相比直接访问主机的文件系统是很慢的。就必须把mysql的日志文件和my.cnf配置文件挂载到主机上。因此容器中都要存储静态文件。
怎么实现读写分离？
判断操作是读还是写？然后把写的操作给主库，读的操作给从库。
方案：中间代理方案。所有的请求由原来的连接到master到连接到中心代理结点proxy。代理结点判断是查操作还是写操作。然后分发到不同的主从结点。
好处：通过中间代理层，就不需要在应用程序里判断是读还是写，再给不同的结点了。更灵活了。
图：中间代理方案实现读写分离
操作：
要配置docker-compose.yml文件，里面是主从结点的镜像、环境、挂载等信息。（https://www.runoob.com/docker/docker-compose.html ）。启动docker-compose就运行整个程序了。
各个主从也有相应的配置文件
然后下载atlas。atlas配置文件。