ITPub博客

首页 > 云计算 > 容器服务 > 【MySQL】 在Docker中快速部署PXC+负载均衡

【MySQL】 在Docker中快速部署PXC+负载均衡

原创 容器服务 作者:lhrbest 时间:2020-04-03 16:10:45 0 删除 编辑


【MySQL】 在Docker中快速部署PXC




参考:

https://www.cnblogs.com/lonelyxmas/p/10584902.html

https://www.cnblogs.com/markLogZhu/p/11463125.html

一键部署PXC: https://github.com/luckman666/deploy_mysql_cluster




一、简介

PXC属于一套近乎完美的mysql高可用集群解决方案,相比那些比较传统的基于主从复制模式的集群架构MHA和MM+keepalived,galera cluster最突出特点就是解决了诟病已久的数据复制延迟问题,基本上可以达到实时同步。而且节点与节点之间,他们相互的关系是对等的。本身galera cluster也是一种多主架构。galera cluster最关注的是数据的一致性,对待事物的行为时,要么在所有节点上执行,要么都不执行,它的实现机制决定了它对待一致性的行为非常严格,这也能非常完美的保证MySQL集群的数据一致性;

对galera cluster的封装有两个,虽然名称不同,但实质都是一样的,使用的都是galera cluster。一个MySQL的创始人在自己全新的MariaDB上实现的MAriaDB cluster;一个是著名的MySQL服务和工具提供商percona实现的percona xtradb cluster,简称PXC

要搭建PXC架构至少需要3个mysql实例来组成一个集群,三个实例之间不是主从模式,而是各自为主,所以三者是对等关系,不分从属,这就叫multi-master架构。客户端写入和读取数据时,连接哪个实例都是一样的。读取到的数据时相同的,写入任意一个实例之后,集群自己会将新写入的数据同步到其他实例上,这种架构不共享任何数据,是一种高冗余架构。

PXC的操作流程:
        首先客户端先发起一个事务,该事务先在本地执行,执行完成之后就要发起对事务的提交操作了。在提交之前需要将产生的复制写集广播出去,然后获取到一个全局的事务ID号,一并传送到另一个节点上面。通过合并数据之后,发现没有冲突数据,执行apply_cd和commit_cb动作,否则就需要取消此次事务的操作。而当前server节点通过验证之后,执行提交操作,并返回OK,如果验证没通过,则执行回滚。当然在生产中至少要有3个节点的集群环境,如果其中一个节点没有验证通过,出现了数据冲突,那么此时采取的方式就是讲出现不一致的节点踢出集群环境,而且它自己会执行shutdown命令,自动关机。

PXC的优点:
        ①实现mysql数据库集群架构的高可用性和数据的 强一致性。
        ②完成了真正的多节点读写的集群方案。
        ③改善了传统意义上的主从复制延迟问题,基本上达到了实时同步。
        ④新加入的节点可以自动部署,无须提供手动备份,维护起来很方便。
        ⑤由于是多节点写入,所以数据库故障切换很容易。

PXC的缺点:
        ①新加入的节点开销大,需要复制完整的数据。采用SST传输开销太大。
        ②任何更新事务都需要全局验证通过,才会在每个节点库上执行。集群性能受限于性能最差的节点,也就是经常说的短板效应。
        ③因为需要保证数据的一致性,所以在多节点并发写时,锁冲突问题比较严重。
        ④存在写扩大问题,所有的节点上都会发生些操作。
        ⑤只支持innodb存储引擎的表。
        ⑥没有表级别的锁定,执行DDL语句操作会把整个集群锁住,而且也 kill 不了(建议使用Osc操作,即在线DDL)
        ⑦所有的表必须含有主键,不然操作数据时会报错。

 

二、环境配置


1、系统:centos7.3

2、docker版本:Docker version 1.13.1, build 07f3374/1.13.1

3、PXC镜像:percona/percona-xtradb-cluster

 

三、安装部署

1、拉取镜像

docker pull percona/percona-xtradb-cluster

成功拉取后的效果如图所示:

 

2、创建docker内部网络

docker network create --subnet=172.18.0.0/24 net1

成功创建的效果如图所示,使用docker network inspect net1命令查看:

创建网络时出现以下错误信息,莫慌,重启docker再次创建即可

 

3、创建docker卷

docker volume create --name v1
docker volume create --name v2
docker volume create --name v3
docker volume create --name v4
docker volume create --name v5

4、查看docker卷信息

docker inspect v1
docker inspect v2
docker inspect v3
docker inspect v4
docker inspect v5

效果如图所示

PS:切记一定要先创建docker卷再创建容器,不能一起来或者会报权限异常,不能创建容器

 

5、创建容器,这里以创建5个容器为例

docker run -di -p 3306:3306 \
-v v1:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=123456 \
-e CLUSTER_NAME=PXC \
-e XTRABACKUP_PASSWORD=123456 \
--privileged=true --name=node1 --net=net1 --ip 172.18.0.2 \
docker.io/percona/percona-xtradb-cluster
docker run -di -p 3307:3306 \
-v v2:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=123456 \
-e CLUSTER_NAME=PXC \
-e XTRABACKUP_PASSWORD=123456 \
-e CLUSTER_JOIN=node1 \
--privileged=true --name=node2 --net=net1 --ip 172.18.0.3 \
docker.io/percona/percona-xtradb-cluster
docker run -di -p 3308:3306 \
-v v3:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=123456 \
-e CLUSTER_NAME=PXC \
-e XTRABACKUP_PASSWORD=123456 \
-e CLUSTER_JOIN=node1 \
--privileged=true --name=node3 --net=net1 --ip 172.18.0.4 \
docker.io/percona/percona-xtradb-cluster
docker run -di -p 3309:3306 \
-v v4:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=123456 \
-e CLUSTER_NAME=PXC \
-e XTRABACKUP_PASSWORD=123456 \
-e CLUSTER_JOIN=node1 \
--privileged=true --name=node4 --net=net1 --ip 172.18.0.5 \
docker.io/percona/percona-xtradb-cluster
docker run -di -p 3310:3306 \
-v v5:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=123456 \
-e CLUSTER_NAME=PXC \
-e XTRABACKUP_PASSWORD=123456 \
-e CLUSTER_JOIN=node1 \
--privileged=true --name=node5 --net=net1 --ip 172.18.0.6 \
docker.io/percona/percona-xtradb-cluster

PS:切记因第一个节点初始化比较耗时一定要等第一个容器创建成功可以使用MySQL客户端连接了才能创建第二个,或者会报错创建不了下面的容器!!!

效果如图:

6、测试集群

1)在node1对应的数据库(pxc-mysql-1)创建数据库mytest

2) 在node5对应的数据库(pxc-mysql-5)查看有没有刚刚在node1所创建的数据库mytest

3) 在node5对应的数据库(pxc-mysql-5)创建一个表mytb,并插入一条数据

4) 在node1对应的数据库(pxc-mysql-1)、node2对应的数据库(pxc-mysql-2)查看是否有刚刚新建的表和数据



MySQL之PXC集群搭建

一、PXC 介绍

1.1 PXC 简介

PXC 是一套  MySQL 高可用集群解决方案,与传统的基于主从复制模式的集群架构相比 PXC 最突出特点就是解决了诟病已久的数据复制延迟问题,基本上可以达到实时同步。而且节点与节点之间,他们相互的关系是对等的。PXC 最关注的是数据的一致性,对待事物的行为时,要么在所有节点上执行,要么都不执行,它的实现机制决定了它对待一致性的行为非常严格,这也能非常完美的保证 MySQL 集群的数据一致性;

1.2 PXC特性和优点

  • 完全兼容 MySQL。

  • 同步复制,事务要么在所有节点提交或不提交。

  • 多主复制,可以在任意节点进行写操作。

  • 在从服务器上并行应用事件,真正意义上的并行复制。

  • 节点自动配置,数据一致性,不再是异步复制。

  • 故障切换:因为支持多点写入,所以在出现数据库故障时可以很容易的进行故障切换。

  • 自动节点克隆:在新增节点或停机维护时,增量数据或基础数据不需要人工手动备份提供,galera cluster会自动拉取在线节点数据,集群最终会变为一致;

PXC最大的优势:强一致性、无同步延迟

1.3 PXC的局限和劣势

  • 复制只支持 InnoDB 引擎,其他存储引擎的更改不复制

  • 写入效率取决于节点中最慢的一台

1.4 PXC与Replication的区别

Replication PXC
数据同步是单向的,master负责写,然后异步复制给slave;如果slave写入数据,不会复制给master。 数据同步时双向的,任何一个mysql节点写入数据,都会同步到集群中其它的节点。
异步复制,从和主无法保证数据的一致性 同步复制,事务在所有集群节点要么同时提交,要么同时不提交

1.5 PXC 常用端口

  • 3306:数据库对外服务的端口号。

  • 4444:请求SST的端口。

  • 4567:组成员之间进行沟通的一个端口号

  • 4568:用于传输IST。

名词解释:

  • SST(State Snapshot Transfer): 全量传输

  • IST(Incremental state Transfer):增量传输


二、实践

2.1 搭建 PXC 集群

与  MySQL 不同的是 PXC 官方提供了  Docker 镜像,所以我们可以很方便的搭建 PXC 集群。

1)下载  Docker 镜像

docker pull percona/percona-xtradb-cluster:5.7
  1. 重命名镜像名称
docker tag percona/percona-xtradb-cluster:5.7 pxc:5.7

3)删除原始镜像

docker rmi percona/percona-xtradb-cluster:5.7
  1. 创建  Docker 网络,用于  PXC 集群独立使用
docker network create pxc-network
  1. 创建数据卷用于之后挂载
docker volume create --name v1
docker volume create --name v2
docker volume create --name v3

注: PXC容器只支持数据卷挂载方式,不支持目录挂载

  1. 创建第一个节点
docker run -di --name=pn1 --net=pxc-network -p 9000:3306 -v v1:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456  pxc:5.7

因为后续节点的添加需要关联到第一个节点,所以需要等待数据库启动完成。通过  docker logs pn1 查看日志,如果出现下面的输出,证明启动成功:

2019-09-04T06:27:30.085880Z 0 [Note] InnoDB: Buffer pool(s) load completed at 190904  6:27:30

注:CLUSTER_NAME 名称不要用关键字 PXC,否则无法启动。

  1. 加入第二个节点
docker run -di --name=pn2 --net=pxc-network -p 9001:3306 -v v2:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456  -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pn1 pxc:5.7

需要注意是第二个节点开始需要增加  e CLUSTER_JOIN=pn1 参数,表示与  pn1 节点同步,否则  pn1 容器会自动关闭。

当  PXC集群中存在两个节点以上之后就没有主节点的概念了。集群中最后一个退出的节点就会变为主节点,在  /var/lib/mysql/grastate.dat 文件中属性  safe_to_bootstrap 的值 会从  0 被设置为  1 表示该节点是主节点。

8)加入第三个节点

docker run -di --name=pn3 --net=pxc-network -p 9002:3306 -v v3:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456  -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pn2 pxc:5.7

可以看到我们这次我们  CLUSTER_JOIN 的是  pn2 容器,可以证明我们刚刚说的  当 PXC 集群存在两个节点以上之后就没有主节点的概念了 这个说法是正确的。

9)进入  pn1 节点

docker exec -it pn1 /usr/bin/mysql -uroot -p123456
  1. 查看状态
mysql> show status like 'wsrep%';
+----------------------------------+-------------------------------------------------+
| Variable_name                    | Value                                           |
+----------------------------------+-------------------------------------------------+
| wsrep_local_state_uuid           | 068dd5e8-cedd-11e9-904d-466e75bd8fe1            |
| wsrep_protocol_version           | 9                                               |
| wsrep_last_applied               | 16                                              |
| wsrep_last_committed             | 16                                              |
| wsrep_replicated                 | 0                                               |
| wsrep_replicated_bytes           | 0                                               |
| wsrep_repl_keys                  | 0                                               |
| wsrep_repl_keys_bytes            | 0                                               |
| wsrep_repl_data_bytes            | 0                                               |
| wsrep_repl_other_bytes           | 0                                               |
| wsrep_received                   | 10                                              |
| wsrep_received_bytes             | 800                                             |
| wsrep_local_commits              | 0                                               |
| wsrep_local_cert_failures        | 0                                               |
| wsrep_local_replays              | 0                                               |
| wsrep_local_send_queue           | 0                                               |
| wsrep_local_send_queue_max       | 1                                               |
| wsrep_local_send_queue_min       | 0                                               |
| wsrep_local_send_queue_avg       | 0.000000                                        |
| wsrep_local_recv_queue           | 0                                               |
| wsrep_local_recv_queue_max       | 2                                               |
| wsrep_local_recv_queue_min       | 0                                               |
| wsrep_local_recv_queue_avg       | 0.100000                                        |
| wsrep_local_cached_downto        | 0                                               |
| wsrep_flow_control_paused_ns     | 0                                               |
| wsrep_flow_control_paused        | 0.000000                                        |
| wsrep_flow_control_sent          | 0                                               |
| wsrep_flow_control_recv          | 0                                               |
| wsrep_flow_control_interval      | [ 173, 173 ]                                    |
| wsrep_flow_control_interval_low  | 173                                             |
| wsrep_flow_control_interval_high | 173                                             |
| wsrep_flow_control_status        | OFF                                             |
| wsrep_cert_deps_distance         | 0.000000                                        |
| wsrep_apply_oooe                 | 0.000000                                        |
| wsrep_apply_oool                 | 0.000000                                        |
| wsrep_apply_window               | 0.000000                                        |
| wsrep_commit_oooe                | 0.000000                                        |
| wsrep_commit_oool                | 0.000000                                        |
| wsrep_commit_window              | 0.000000                                        |
| wsrep_local_state                | 4                                               |
| wsrep_local_state_comment        | Synced                                          |
| wsrep_cert_index_size            | 0                                               |
| wsrep_cert_bucket_count          | 22                                              |
| wsrep_gcache_pool_size           | 1592                                            |
| wsrep_causal_reads               | 0                                               |
| wsrep_cert_interval              | 0.000000                                        |
| wsrep_open_transactions          | 0                                               |
| wsrep_open_connections           | 0                                               |
| wsrep_ist_receive_status         |                                                 |
| wsrep_ist_receive_seqno_start    | 0                                               |
| wsrep_ist_receive_seqno_current  | 0                                               |
| wsrep_ist_receive_seqno_end      | 0                                               |
| wsrep_incoming_addresses         | 172.19.0.2:3306,172.19.0.3:3306,172.19.0.4:3306|
| wsrep_cluster_weight             | 3                                               |
| wsrep_desync_count               | 0                                               |
| wsrep_evs_delayed                |                                                 |
| wsrep_evs_evict_list             |                                                 |
| wsrep_evs_repl_latency           | 0/0/0/0/0                                       |
| wsrep_evs_state                  | OPERATIONAL                                     |
| wsrep_gcomm_uuid                 | 11ed51e2-cedd-11e9-b362-af453a7ac074            |
| wsrep_cluster_conf_id            | 3                                               |
| wsrep_cluster_size               | 3                                               |
| wsrep_cluster_state_uuid         | 068dd5e8-cedd-11e9-904d-466e75bd8fe1            |
| wsrep_cluster_status             | Primary                                         |
| wsrep_connected                  | ON                                              |
| wsrep_local_bf_aborts            | 0                                               |
| wsrep_local_index                | 0                                               |
| wsrep_provider_name              | Galera                                          |
| wsrep_provider_vendor            | Codership Oy <info@codership.com>               |
| wsrep_provider_version           | 3.37(rff05089)                                  |
| wsrep_ready                      | ON                                              |
+----------------------------------+-------------------------------------------------+
71 rows in set (0.06 sec)

可以看到  wsrep_incoming_addresses 的值就是我们三个容器的IP地址

| wsrep_incoming_addresses         | 172.19.0.2:3306,172.19.0.3:3306,172.19.0.4:3306 |

集群完整性检查:

属性 含义
wsrep_cluster_state_uuid 在集群所有节点的值应该是相同的,有不同值的节点,说明其没有连接入集群.
wsrep_cluster_conf_id 正常情况下所有节点上该值是一样的.如果值不同,说明该节点被临时”分区”了.当节点之间网络连接恢复 的时候应该会恢复一样的值.
wsrep_cluster_size 如果这个值跟预期的节点数一致,则所有的集群节点已经连接.
wsrep_cluster_status 集群组成的状态.如果不为”Primary”,说明出现”分区”或是”split-brain”脑裂状况.

节点状态检查:

属性 含义
wsrep_ready 该值为 ON,则说明可以接受 SQL 负载.如果为 Off,则需要检查 wsrep_connected
wsrep_connected 如果该值为 Off,且 wsrep_ready 的值也为 Off,则说明该节点没有连接到集群.(可能是 wsrep_cluster_address 或 wsrep_cluster_name 等配置错造成的.具体错误需要查看错误日志)
wsrep_local_state_comment 如果 wsrep_connected 为 On,但 wsrep_ready 为 OFF,则可以从该项查看原因

复制健康检查:

属性 含义
wsrep_flow_control_paused 表示复制停止了多长时间.即表明集群因为 Slave 延迟而慢的程度.值为 0~1,越靠近 0 越好,值为 1 表示 复制完全停止.可优化 wsrep_slave_threads 的值来改善
wsrep_cert_deps_distance 有多少事务可以并行应用处理.wsrep_slave_threads 设置的值不应该高出该值太多
wsrep_flow_control_sent 表示该节点已经停止复制了多少次
*wsrep_local_recv_queue_avg 表示 slave 事务队列的平均长度.slave 瓶颈的预兆. 最慢的节点的 wsrep_flow_control_sent 和 wsrep_local_recv_queue_avg 这两个值最高.这两个值较低的话,相对更好

检测慢网络问题:

属性 含义
wsrep_local_send_queue_avg 网络瓶颈的预兆.如果这个值比较高的话,可能存在网络瓶颈

冲突或死锁的数目:

属性 含义
wsrep_last_committed 最后提交的事务数目
wsrep_local_cert_failures 和 wsrep_local_bf_aborts 回滚,检测到的冲突数目

2.2 集群同步验证

  1. 在节点一上创建数据库  test
mysql> create database test;
Query OK, 1 row affected (0.02 sec)
  1. 节点二上查看:
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
+--------------------+
5 rows in set (0.00 sec)
  1. 在节点二上创建表
mysql> use test;
Database changed
mysql> create table sys_user(id int ,name varchar(30));
Query OK, 0 rows affected (0.11 sec)

4)在节点三上查看表结构

mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| sys_user       |
+----------------+1 row in set (0.00 sec)
  1. 在节点三上插入数据
mysql> insert into sys_user values(1,'a');
ERROR 1105 (HY000): Percona-XtraDB-Cluster prohibits use of DML command on a table (test.sys_user) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER

看到没有显示的主键就无法插入数据,我们修改下表结构:

alter table sys_user add primary key (id);

插入数据:

mysql> insert into sys_user values(1,'a');
Query OK, 1 row affected (0.05 sec)

6)在节点一查看表数据

mysql> select * from sys_user;
+----+------+
| id | name |
+----+------+
|  1 | a    |
+----+------+
1 row in set (0.00 sec)

可以看到三个节点数据正常同步,并且都可读可写。

2.3 新增数据库节点操作

当数据库不够用时,我们通常需要增加数据库节点来分担压力,我们来演示一下新增节点的操作。

  1. 创建数据卷
docker volume create --name v4

2)新增容器

docker run -di --name=pn4 --net=pxc-network -p 9003:3306 -v v4:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456  -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pn3 pxc:5.7

要注意的是,这次  CLUSTER_JOIN 连的是  pn3

  1. 进入节点4查看数据
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
+--------------------+5 rows in set (0.00 sec)
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| sys_user       |
+----------------+
1 row in set (0.00 sec)
mysql> select * from sys_user;
+----+------+
| id | name |
+----+------+
|  1 | a    |
+----+------+
1 row in set (0.00 sec)

可以看到之前的数据也自动同步过来了。

2.4 宕机操作

  1. 将节点 pn4容器关闭,造成宕机现象
docker stop pn4
  1. 在节点  pn2 上做查看集群状态
mysql> show status like 'wsrep%';
......
| wsrep_local_state                | 4                                               |
| wsrep_local_state_comment        | Synced                                          |
| wsrep_cert_index_size            | 3                                               |
......
| wsrep_incoming_addresses         | 172.19.0.4:3306,172.19.0.3:3306,172.19.0.2:3306 |

可以看到集群应该有4个节点,但是现在只有3个正常连接。

3)在节点  pn2 上做修改操作

mysql> update sys_user set name='b' where id=1; 
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
  1. 将节点  pn4 容器启动
[root@VM_0_15_centos ~]# docker start pn4
  1. 进入容器  pn4 查看修改操作是否同步
docker exec -it pn4 /usr/bin/mysql -uroot -p123456
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from sys_user;
+----+------+
| id | name |
+----+------+
|  1 | b    |
+----+------+
1 row in set (0.00 sec)

可以看到节点正常加入集群,并且数据也同步了。

pn4 是以指定主节点形式进入  PXC 集群创建的容器,那么  pn1直接以自身为主节点启动的容器会怎么样呢?我们来演示一下:

  1. 关闭  pn1 节点
docker stop pn1
  1. 在  pn2 节点上插入一条数据
mysql> insert into sys_user values('2','c');
Query OK, 1 row affected (0.01 sec)
  1. 启动  pn1节点
docker start pn1

等待一分钟,查看容器启动列表

docker ps -a

发现  pn1 节点并没有启动

CONTAINER ID        IMAGE    ......   STATUS                           NAMES
fa123563e787        pxc:5.7  ......   Exited (1) About a minute ago    pn1

查看下错误日志:

docker logs pn1

异常信息如下:

2019-09-04T07:21:56.412918Z 0 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .2019-09-04T07:21:56.412922Z 0 [ERROR] WSREP: Provider/Node (gcomm://) failed to establish connection with cluster (reason: 7)2019-09-04T07:21:56.412929Z 0 [ERROR] Aborting

翻译成中文:

2019-09-04T07:21:56.412918Z 0 [错误] WSREP:从此节点引导群集可能不安全。 它不是离开群集的最后一个,可能不包含所有更新。 要使用此节点强制群集引导,请手动编辑grastate.dat文件并将safe_to_bootstrap设置为1。2019-09-04T07:21:56.412922Z 0 [错误] WSREP:提供者/节点(gcomm://)无法与群集建立连接(原因:7)2019-09-04T07:21:56.412929Z 0 [错误]中止

错误提示很明显了,因为  pn1 节点不是最后一个离开集群的不能再以主节点的形式启动了,如果要以主节点的形式启动必须调整  grastate.dat文件中的  safe_to_bootstrap 参数为  1

但是要注意的是因为集群中其他节点并没有关闭,这样启动的容器跟之前的集群就没有关系了数据也不会同步,我们来验证下看看:

  1. 查看数据卷存放的路径
docker volume inspect v1
[
    {        "CreatedAt": "2019-09-05T09:22:22+08:00",        "Driver": "local",        "Labels": {},        "Mountpoint": "/var/lib/docker/volumes/v1/_data",        "Name": "v1",        "Options": {},        "Scope": "local"
    }
]
  1. 进入数据卷目录,查看是否存在  grastate.dat文件
[root@VM_0_15_centos ~]# cd /var/lib/docker/volumes/v1/_data
[root@VM_0_15_centos _data]# ll
total 323444-rw-r----- 1 1001 1001        56 Sep  5 08:34 auto.cnf
-rw------- 1 1001 1001      1680 Sep  5 08:34 ca-key.pem
-rw-r--r-- 1 1001 1001      1120 Sep  5 08:34 ca.pem
-rw-r--r-- 1 1001 1001      1120 Sep  5 08:34 client-cert.pem
-rw------- 1 1001 1001      1676 Sep  5 08:34 client-key.pem
-rw-r----- 1 1001 1001         2 Sep  5 08:34 fa123563e787.pid
-rw-r----- 1 1001 1001 134219048 Sep  5 09:22 galera.cache
-rw-r----- 1 1001 1001       113 Sep  5 09:21 grastate.dat
-rw-r----- 1 1001 1001      1300 Sep  5 08:34 ib_buffer_pool
-rw-r----- 1 1001 1001  79691776 Sep  5 09:15 ibdata1
-rw-r----- 1 1001 1001  50331648 Sep  5 09:15 ib_logfile0
-rw-r----- 1 1001 1001  50331648 Sep  5 08:34 ib_logfile1
-rw-r----- 1 1001 1001  12582912 Sep  5 08:38 ibtmp1
-rw-r----- 1 1001 1001     34751 Sep  5 08:38 innobackup.backup.log
drwxr-x--- 2 1001 1001      4096 Sep  5 08:34 mysql
drwxr-x--- 2 1001 1001      4096 Sep  5 08:34 performance_schema
-rw------- 1 1001 1001      1676 Sep  5 08:34 private_key.pem
-rw-r--r-- 1 1001 1001       452 Sep  5 08:34 public_key.pem
-rw-r--r-- 1 1001 1001      1120 Sep  5 08:34 server-cert.pem
-rw------- 1 1001 1001      1676 Sep  5 08:34 server-key.pem
drwxr-x--- 2 1001 1001     12288 Sep  5 08:34 sys
drwxr-x--- 2 1001 1001      4096 Sep  5 09:07 test
-rw-r--r-- 1 1001 1001       143 Sep  5 09:22 version_info
-rw-r----- 1 1001 1001   3932160 Sep  5 09:15 xb_doublewrite
  1. 编辑文件
vim grastate.dat

将  safe_to_bootstrap 参数值修改为1,保存退出

# GALERA saved state
version: 2.1uuid:    068dd5e8-cedd-11e9-904d-466e75bd8fe1
seqno:   20safe_to_bootstrap: 1
  1. 重启  pn1 容器
docker start pn1
  1. 进入容器,查看数据
docker exec -it pn1 /usr/bin/mysql -uroot -p123456
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from sys_user;
+----+------+
| id | name |
+----+------+
|  1 | b    |
+----+------+1 row in set (0.01 sec)

发现数据并没有同步,那么要怎么将  pn1 节点加入到集群中呢?

我们可以直接将  pn1 容器删除,以加入节点的形式重新创建容器,并且因为我们之前已经将容器的数据挂载到数据卷了,所以数据也不会存在丢失的风险,我们来操作下:

  1. 删除  pn1容器
docker stop pn1
docker rm pn1
  1. 以从节点方式加入集群
docker run -di --name=pn1 --net=pxc-network -p 9000:3306 -v v1:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456  -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pn2 pxc:5.7

等待容器初始化完毕

3)进入容器,查看数据是否同步

docker exec -it pn1 /usr/bin/mysql -uroot -p123456
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from sys_user;
+----+------+
| id | name |
+----+------+
|  1 | b    |
|  2 | c    |
+----+------+2 rows in set (0.00 sec)

发现数据已经同步了。






一键部署PXC: https://github.com/luckman666/deploy_mysql_cluster


git clone https://github.com/luckman666/deploy_mysql_cluster.git

cd deploy_mysql_cluster && chmod -R 755 .

# 编辑 bash.config 参数

./deploy_mysql_master.sh

以上几步就完成了一套多节点多主多从故障自动切换的mysql 数据库集群。

使用及注意事项:

如果集群出现某一节点出现故障:

1 、集群会立刻将其剔除集群,停止同步。

2 、(主节点故障) keepalived 两秒内会感知 mysql 故障,从集群中踢除本节点 mysql ,本节点降权并将 VIP 漂移至完好节点,整个集群继续提供服务。

3 、(从节点故障) keepalived 直接关闭该节点服务,将该节点剔除集群。

故障修复后加入集群方式:

恢复节点上执行此命令(注意修改参数):

docker run -d -p 3306:3306 -p 4444:4444 -p 4567:4567 -p 4568:4568 -e MYSQL_ROOT_PASSWORD=root -e CLUSTER_NAME=PXC -e CLUSTER_JOIN= 主节点主机名( mysql1 -e XTRABACKUP_PASSWORD=root -v /opt/mysql/data:/var/lib/mysql -v /opt/mysql/backup:/data -v /etc/localtime:/etc/localtime:ro -v /var/run/docker.sock:/var/run/docker.sock --privileged --name= 本节点主机名(如: mysql2 --net=swarm_mysql docker.io/percona/percona-xtradb-cluster

同步完成后启动再keepalived

systemctl restart keepalived

检查keepalived 启动状态

systemctl status keepalived

通过工具或者查看容器日志查看mysql 运行是否良好!

     设计这套mysql 的集群方案主要是面向我司的账单系统。因为都是账单数据,对于数据的丢失的容忍度为 0 。所以采用多节点强制同步的 PXC 集群方式。部署采用 docker 方式,网络方案采用 swarm overlay 网络,冗余策略是 keepalived





「实战篇」开源项目docker化运维部署-搭建mysql集群(四)

有了docker虚拟机,就需要利用平台部署数据库的集群,在实际操作之前介绍下数据库集群的方案和各自的特点。源码: https://github.com/limingios/netFuture/tree/master/mysql-pxc/


集群的方案

单节点的弊病

  1. 大型互联网程序用户群体庞大,所以架构必须要特殊设计
  2. 单节点的数据库无法满足性能的要求

案例15年前,高考成绩可以在网上查(河南几十万考生),那时候基本家里都没电脑,都是去网吧白天去网吧也查不了,太慢了,后来半夜通宵有时候可以查到,也就是说白天基本查不了人太多了。晚上看运气。一个数据库的实例1万多人就无法反应了。

  1. 单节点的数据库没有冗余设计,无法满足高可用

常用的mysql集群设计方案

  • Replication
  1. 速度快
  2. 弱一致性
  3. 低价值
  4. 场景:日志,新闻,帖子
  • PXC
  1. 速度慢
  2. 强一致性
  3. 高价值
  4. 场景:订单,账户,财务

Percona Xtradb Cluster,简称PXC。是基于Galera插件的MySQL集群。相比那些比较传统的基于主从复制模式的集群架构MHA和MM+keepalived,galera cluster最突出特点就是解决了诟病已久的数据复制延迟问题,基本上可以达到实时同步。而且节点与节点之间,他们相互的关系是对等的。本身galera cluster也是一种多主架构。galera cluster最关注的是数据的一致性,对待事物的行为时,要么在所有节点上执行,要么都不执行,它的实现机制决定了它对待一致性的行为非常严格,这也能非常完美的保证MySQL集群的数据一致性。在PXC里面任何一个节点都是可读可写的。在其他的节点一定是可以读取到这个数据。

  • 建议PXC使用PerconaServer(MYSQL的改进版,性能提升很大)
  • PXC方案和Replication方案的对比

PXC任意一个节点都可以存在读写的方案,也就是任意一个节点都可以当读或者当写。同步复制。保证强一致性。

Replication方案,主从的方式,他是采用异步的方式。

  • PXC的数据强一致性

同步复制,事务在所有节点要提交都提交。要么都不提交

  • Replication弱一致性,主要master成功就成功了。返回给调用者。如果slave失败,也没办法。因为已经告诉调用者成功了,调用者获取查询的时候查询不到信息。例如:在淘宝买个东西,付款也成功了,查询订单没信息是不是要骂娘。

环境搭建

应用 IP地址 服务 配置 安装应用 安装方式
docker-mysql 192.168.66.100 docker-mysql 双核 8g内存 docker-mysql docker

(1). 虚拟机vagrant讲述安装的步骤

vagrant up

(2).机器window/mac开通远程登录root用户下

su -
# 密码
vagrant
#设置 PasswordAuthentication yes
vi /etc/ssh/sshd_config
sudo systemctl restart sshd

PXC集群安装介绍

PXC既可以在linux系统安装,也可以在docker上面安装。

  • 安装镜像PXC镜像
docker pull percona/percona-xtradb-cluster
#本地安装
docker load </home/soft/pxc.tar.gz
  • 创建内部网络的

处于安全,需要给PXC集群实例创建Docker内部网络,都出可虚拟机自带的网段是172.17.0. , 这是内置的一个网段,当你创建了网络后,网段就更改为172.18.0.

docker network create net1
docker network inspect net1
docker network rm net1
#设置网段
docker network create  --subnet=172.18.0.0/24 net1
  • 创建Docker 卷

一旦生成docker容器,不要在容器内保存业务的数据,要把数据放到宿主机上,可以把宿主机的一个目录映射到容器内,如果容器出现问题,只需要吧容器删除,重新建立一个新的容器把目录映射给新的容器。

之前一直有个疑问,如果直接映射目录的吧,存在失败的问题,现在终于知道解决方案了,直接映射docker卷就可以可以忽略这个问题了。

容器中的PXC节点映射数据目录的解决方法

docker volume create name --v1

mysql pxc搭建

  • 脚本开发
#!/bin/bash
echo "创建网络"
docker network create  --subnet=172.18.0.0/24 net1
echo "创建5个docker卷"
docker volume create v1
docker volume create v2
docker volume create v3
docker volume create v4
docker volume create v5
echo "创建节点 node1"
docker run -d -p 3306:3306  --net=net1 --name=node1 \
        -e CLUSTER_NAME=PXC \
        -e MYSQL_ROOT_PASSWORD=a123456 \
        -e XTRABACKUP_PASSWORD=a123456 \
        -v v1:/var/lib/mysql \
        --privileged \
        --ip 172.18.0.2 \
        percona/percona-xtradb-cluster
sleep 1m 
echo "创建节点 node2"
docker run -d -p 3307:3306  --net=net1 --name=node2 \
        -e CLUSTER_NAME=PXC \
        -e MYSQL_ROOT_PASSWORD=a123456 \
        -e XTRABACKUP_PASSWORD=a123456 \
        -e CLUSTER_JOIN=node1 \
        -v v2:/var/lib/mysql \
        --privileged \
        --ip 172.18.0.3 \
        percona/percona-xtradb-cluster
sleep 1m 
echo "创建节点 node3"
docker run -d -p 3308:3306  --net=net1 --name=node3 \
        -e CLUSTER_NAME=PXC \
        -e MYSQL_ROOT_PASSWORD=a123456 \
        -e XTRABACKUP_PASSWORD=a123456 \
        -e CLUSTER_JOIN=node1 \
        -v v3:/var/lib/mysql \
        --privileged \
        --ip 172.18.0.4 \
        percona/percona-xtradb-cluster
sleep 1m 
echo "创建节点 node4"
docker run -d -p 3309:3306  --net=net1 --name=node4 \
        -e CLUSTER_NAME=PXC \
        -e MYSQL_ROOT_PASSWORD=a123456 \
        -e XTRABACKUP_PASSWORD=a123456 \
        -e CLUSTER_JOIN=node1 \
        -v v4:/var/lib/mysql \
        --privileged \
        --ip 172.18.0.5 \
        percona/percona-xtradb-cluster
sleep 1m 
echo "创建节点 node5"
docker run -d -p 3310:3306  --net=net1 --name=node5 \
        -e CLUSTER_NAME=PXC \
        -e MYSQL_ROOT_PASSWORD=a123456 \
        -e XTRABACKUP_PASSWORD=a123456 \
        -e CLUSTER_JOIN=node1 \
        -v v5:/var/lib/mysql \
        --privileged \
        --ip 172.18.0.6 \
        percona/percona-xtradb-cluster

新建立一个aaa数据库 结果都可以用

哇塞就这么简单,成功的搭建了mysql的集群

增加负载均衡方案

目前数据库都是独立的ip,在开发的时候总不能随机连接一个数据库吧。如果想请求,统一的口径,这就需要搭建负载均衡了。虽然上边已经搭建了集群,但是不使用数据库负载均衡,单节点处理所有请求,负载高,性能差。下图就是一个节点很忙,其他节点很闲。

  • 调整后的方案,使用Haproxy做负载均衡,请求被均匀分发到每个节点,单节点的负载低,性能好。haproxy不是数据库,只是一个转发器。
  • 负载均衡中间件对比

LVS是不能在虚拟机环境下安装的。

  • 安装haproxy

docker-haproxy的介绍: https://hub.docker.com/_/haproxy/

  • 配置文件
mkdir haproxy/h1
pwd
vi haproxy.cfg
  • haproxy.cfg配置

登录:admin
密码:abc123456

global
    #工作目录
    chroot /usr/local/etc/haproxy
    #日志文件,使用rsyslog服务中local5日志设备(/var/log/local5),等级info
    log 127.0.0.1 local5 info
    #守护进程运行
    daemon
defaults
    log global
    mode    http
    #日志格式
    option  httplog
    #日志中不记录负载均衡的心跳检测记录
    option  dontlognull
    #连接超时(毫秒)
    timeout connect 5000
    #客户端超时(毫秒)
    timeout client  50000
    #服务器超时(毫秒)
    timeout server  50000
#监控界面   
listen  admin_stats
    #监控界面的访问的IP和端口
    bind  0.0.0.0:8888
    #访问协议
    mode        http
    #URI相对地址
    stats uri   /dbs
    #统计报告格式
    stats realm     Global\ statistics
    #登陆帐户信息
    stats auth  admin:abc123456
#数据库负载均衡
listen  proxy-mysql
    #访问的IP和端口
    bind  0.0.0.0:3306  
    #网络协议
    mode  tcp
    #负载均衡算法(轮询算法)
    #轮询算法:roundrobin
    #权重算法:static-rr
    #最少连接算法:leastconn
    #请求源IP算法:source 
    balance  roundrobin
    #日志格式
    option  tcplog
    #在MySQL中创建一个没有权限的haproxy用户,密码为空。Haproxy使用这个账户对MySQL数据库心跳检测
    option  mysql-check user haproxy
    server  MySQL_1 172.18.0.2:3306 check weight 1 maxconn 2000  
    server  MySQL_2 172.18.0.3:3306 check weight 1 maxconn 2000  
    server  MySQL_3 172.18.0.4:3306 check weight 1 maxconn 2000 
    server  MySQL_4 172.18.0.5:3306 check weight 1 maxconn 2000
    server  MySQL_5 172.18.0.6:3306 check weight 1 maxconn 2000
    #使用keepalive检测死链
    option  tcpka
  • 创建docker下的haproxy容器
docker run -it -d -p 4001:8888 \
-p 4002:3306 \
-v /root/haproxy/h1:/usr/local/etc/haproxy \
--name h1 --privileged --net=net1 \
--ip 172.18.0.7 haproxy
  • 进入容器后,加载配置文件
docker exec -it h1 /bin/bash
haproxy -f /usr/local/etc/haproxy/haproxy.cfg
  • 在数据库中创建一个haproxy的用户,不需要设置密码
  • 登录haproxy网页端

http://192.168.66.100:4001/dbs

  • 客户端连接haproxy-mysql数据库

正常的连接haproxy,传递增删盖查,其实是通过轮询的方式。选择mysql的节点。均匀的分发给mysql的实例。不会吧数据库的请求都集中在一个节点上。把请求分散出去,每个数据库实例获取到的请求就小很多了。这就是数据库的负载。

  • 虚拟机重启后,发现pxc起不起来了

查看日志发现,node1无法启动,输入命令查看docker logs node1

It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

解决方案

#查看node1挂载点的文件地址
docker volume inspect v1   
# 进入目录下
cd /var/lib/docker/volumes/v1/_data
#编辑文件grastate.dat
vi grastate.dat

高可用负载均衡方案

目前haproxy只有一个,单haproxy不具备高可用,必须冗余设计。haproxy不能形成瓶颈。

  • 虚拟IP技术

haproxy双机互备离不开一个关键的技术,这个技术是虚拟IP,linux可以在一个网卡内定义多个虚拟IP,得把这些IP地址定义到一个虚拟IP。

  • 利用keepalived实现双机热备

定义出来一个虚拟IP,这个方案叫双机热备,准备2个keepalived,keepalived 就是为了抢占虚拟IP的,谁手快谁能抢到,没抢到的处于等待的状态。抢到的叫做主服务器,未抢到的叫做备服务器。两个keepalived之前有心跳检测的,当备用的检测到主服务挂了,就立马抢占虚拟IP。

  • Haproxy双机热备方案


  • 安装keepalived

keepalived必须在haproxy所在的容器之内,也可以在docker仓库里面下载一个haproxy-keepalived的镜像。这里直接在容器内安装keepalived。

docker exec -it h1 /bin/bash
#写入dns,防止apt-get update找不到服务器
echo "nameserver 8.8.8.8" | tee /etc/resolv.conf > /dev/null 
apt-get clean
apt-get update
apt-get install vim
vi /etc/apt/sources.list

sources.list 添加下面的内容

deb http://mirrors.163.com/ubuntu/ precise main universe restricted multiverse 
deb-src http://mirrors.163.com/ubuntu/ precise main universe restricted multiverse 
deb http://mirrors.163.com/ubuntu/ precise-security universe main multiverse restricted 
deb-src http://mirrors.163.com/ubuntu/ precise-security universe main multiverse restricted 
deb http://mirrors.163.com/ubuntu/ precise-updates universe main multiverse restricted 
deb http://mirrors.163.com/ubuntu/ precise-proposed universe main multiverse restricted 
deb-src http://mirrors.163.com/ubuntu/ precise-proposed universe main multiverse restricted 
deb http://mirrors.163.com/ubuntu/ precise-backports universe main multiverse restricted 
deb-src http://mirrors.163.com/ubuntu/ precise-backports universe main multiverse restricted 
deb-src http://mirrors.163.com/ubuntu/ precise-updates universe main multiverse restricted
  • 更新apt源
apt-get clean
apt-get update
apt-get install keepalived
apt-get install vim
  • keepalived配置文件

容器内的路径:/etc/keepalived/keepalived.conf

vi /etc/keepalived/keepalived.conf
  1. VI_1 名称可以自定义
  2. state MASTER | keepalived的身份(MASTER主服务器,BACKUP备份服务器,不会抢占虚拟机ip)。如果都是主MASTER的话,就会进行互相争抢IP,如果抢到了就是MASTER,另一个就是SLAVE。
  3. interface网卡,定义一个虚拟IP定义到那个网卡上边。网卡设备的名称。eth0是docker的虚拟网卡,宿主机是可以访问的。
  4. virtual_router_id 51 | 虚拟路由标识,MASTER和BACKUP的虚拟路由标识必须一致。标识可以是0-255。
  5. priority 100 | 权重。MASTER权重要高于BACKUP 数字越大优选级越高。可以根据硬件的配置来完成,权重最大的获取抢到的级别越高。
  6. advert_int 1 | 心跳检测。MASTER与BACKUP节点间同步检查的时间间隔,单位为秒。主备之间必须一致。
  7. authentication | 主从服务器验证方式。主备必须使用相同的密码才能正常通信。进行心跳检测需要登录到某个主机上边所有有账号密码。
  8. virtual_ipaddress | 虚拟ip地址,可以设置多个虚拟ip地址,每行一个。根据上边配置的eth0上配置的ip。
  • 启动keeplived

容器内启动

service keepalived start

宿主机ping这个ip

ping 172.18.0.201
创建haproxy2容器,并配置与haproxy1相同的环境

因为要保证有2个haproxy 和keepalived,这次就不那么麻烦了。直接对一个镜像里面包括keeplived 和 haproxy。

  • 宿主机创建文件
mkdir haproxy/h2
cd haproxy/h2
vi haproxy.cfg
vi keepalived.cfg
  • haproxy.cfg
global
    #工作目录
    chroot /usr/local/etc/haproxy
    #日志文件,使用rsyslog服务中local5日志设备(/var/log/local5),等级info
    log 127.0.0.1 local5 info
    #守护进程运行
    daemon
defaults
    log global
    mode    http
    #日志格式
    option  httplog
    #日志中不记录负载均衡的心跳检测记录
    option  dontlognull
    #连接超时(毫秒)
    timeout connect 5000
    #客户端超时(毫秒)
    timeout client  50000
    #服务器超时(毫秒)
    timeout server  50000
#监控界面   
listen  admin_stats
    #监控界面的访问的IP和端口
    bind  0.0.0.0:8888
    #访问协议
    mode        http
    #URI相对地址
    stats uri   /dbs
    #统计报告格式
    stats realm     Global\ statistics
    #登陆帐户信息
    stats auth  admin:abc123456
#数据库负载均衡
listen  proxy-mysql
    #访问的IP和端口
    bind  0.0.0.0:3306  
    #网络协议
    mode  tcp
    #负载均衡算法(轮询算法)
    #轮询算法:roundrobin
    #权重算法:static-rr
    #最少连接算法:leastconn
    #请求源IP算法:source 
    balance  roundrobin
    #日志格式
    option  tcplog
    #在MySQL中创建一个没有权限的haproxy用户,密码为空。Haproxy使用这个账户对MySQL数据库心跳检测
    option  mysql-check user haproxy
    server  MySQL_1 172.18.0.2:3306 check weight 1 maxconn 2000  
    server  MySQL_2 172.18.0.3:3306 check weight 1 maxconn 2000  
    server  MySQL_3 172.18.0.4:3306 check weight 1 maxconn 2000 
    server  MySQL_4 172.18.0.5:3306 check weight 1 maxconn 2000
    server  MySQL_5 172.18.0.6:3306 check weight 1 maxconn 2000
    #使用keepalive检测死链
    option  tcpka
  • keepalived.cfg
vrrp_instance  VI_1 {
    state  MASTER
    interface  eth0
    virtual_router_id  51
    priority  100
    advert_int  1
    authentication {
        auth_type  PASS
        auth_pass  123456
    }
    virtual_ipaddress {
        172.18.0.201
    }
}
  • docker的方式一下安装好 haproxy 和keepalived

https://hub.docker.com/r/pelin/haproxy-keepalived/
映射端口更改为4003 4004 name修改h2

docker run -it -d --privileged -p 4003:8888\
    -p 4004:3306 \
    -v /root/haproxy/h2/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg \
    -v /root/haproxy/h2/keepalived.conf:/etc/keepalived/keepalived.conf \
    --name haproxy-keepalived \
    --net=net1 \
    --name h2 \
    --ip 172.18.0.8 \
    pelin/haproxy-keepalived

宿主机安装keepalived

yum -y install keepalived
vi /etc/keepalived/keepalived.conf
#删除这个表里之前存在的内容
  • keepalived.cof
 vrrp_instance VI_1 {
        state MASTER
        interface eth0
        virtual_router_id 51
        priority 100
        advert_int 1
        authentication {
            auth_type PASS
            auth_pass 1111
        }
        virtual_ipaddress {
            192.168.66.200
        }
    }
    virtual_server 192.168.66.200 8888 {
        delay_loop 3
        lb_algo rr
        lb_kind NAT
        persistence_timeout 50
        protocol TCP
        real_server 172.18.0.201 8888 {
            weight 1
        }
    }
    virtual_server 192.168.66.200 3306 {
        delay_loop 3
        lb_algo rr
        lb_kind NAT
        persistence_timeout 50
        protocol TCP
        real_server 172.18.0.201 3306 {
            weight 1
        }
    }
  • 启动宿主机
service keepalived start

虚拟机端口转发 外部无法访问

WARNING: IPv4 forwarding is disabled. Networking will not work.
  • 解决方案

宿主机修改

vi /etc/sysctl.conf
# 添加net.ipv4.ip_forward=1
systemctl restart network

PS:如果通过docker的方式直接拉取haproxy和keepalived镜像,比直接在镜像里面安装应用方便很多,建议各位老铁尽量避免在容器内安装应用,这样真心麻烦不爽,别人封装的镜像根据pull的量好好看看api就可以使用了。像h1如果容器stop后,重新start,还需要进入容器把keeplived给起起来。而h2直接start里面的haproxy和keeplived,同时都起起来了。 两个容器的采用的热备的方案,让用户毫无感知,切换ip的形式真是美滋滋。mysql集群的高性能,高负载,高可用基本完成了,可用按照这个思路搭建不同的主机下。


mysql 热备份数据(五)







mysql 热备份数据




冷备份

  1. 冷备份是关闭数据库时候的备份方式,通常做法是拷贝数据文件
  2. 冷备份是最简单最安全的一种备份方式
  3. 大型网站无法做到关闭业务备份数据,所以冷备份不是最佳选择
  • PXC冷备份方案

先让其中的一个PXC下线,然后通过拷贝数据文件的方式完成备份,备份完毕下线的PXC上线,完整于其他节点的自动同步。

热备份

  1. 热备份是在系统运行的状态下备份数据,也是难度最大的备份。举个例子,如果淘宝下线1个小时备份数据,淘宝损失多少钱,谁受的的了啊。这都是白花花的银子啊。
  2. Mysql常用的热备份有LVM和XtraBackup两种方案。LVM是针对的分区备份,针对linux系统下的,他号称任何一种数据库都可以完成备份,但是有个弊端,就是在备份的时候只能读不能写入。
  3. 建议使用XtrBackup热备Mysql,不需要锁,备份的时候即可读也可以写,XtraBackup而且还是免费的。

XtrBackup

是一款基于InnoDB的在线热备工具,具有开源免费的,支持在线热备,占用磁盘空间小,能够非常快速的备份与恢复mysql数据库。它支持mysql的各种衍生版本。

  • XtraBackup优势
  1. 备份过程不锁表,快速可靠
  2. 备份过程不会打断正在执行的事务
  3. 能够基于压缩等功能节约磁盘空间和流量
  • 全量备份和增量备份
  1. 全量备份是备份全部数据,备份过程时间,占用空间大。
  2. 增量备份是只备份变化的那部分数据。备份时间短。占用空间小。

在正常的生产系统上,一般是一周做一次全量的备份,一周做一次增量的备份。就足够了。

XtraBackup 安装

  • 准备工作

这个工具要求在数据库的节点之内。备份的出来的数据就直接。需要创建一个数据卷,他用来备份XtraBackup 产生的文件,然后映射到宿主机的磁盘里面。

创建数据卷

docker volume create backup

停止其中一个节点,这里选择node1,目的就是为了删除node1,增加新创建的数据卷。已经运行的容器是不可以增加新的数据卷的。只要还挂载v1的数据卷,v1的文件并没有删除,所以数据不会丢失。

docker stop node1
docker rm node1

重新安装node1 挂载新的节点,并同步其他4个节点。 --CLUSTER_JONIN=node2 新创建的node1,同步node2节点。

docker run -d -p 3306:3306  --net=net1 --name=node1 \
        -e CLUSTER_NAME=PXC \
        -e MYSQL_ROOT_PASSWORD=a123456 \
        -e XTRABACKUP_PASSWORD=a123456 \
        -v v1:/var/lib/mysql \
        --privileged \
        --ip 172.18.0.2 \
        -v backup:/data \
        -e CLUSTER_JOIN=node2 \
        percona/percona-xtradb-cluster
  • PXC 全量备份数据

PXC容器中安全XtraBackup,并执行备份,后悔啊当初PXC的时候没直接找个带XtraBackup的镜像。

docker exec -it --user root node1
echo "nameserver 8.8.8.8" | tee /etc/resolv.conf > /dev/null 
apt-get clean
apt-get update
apt-get install vim
vi /etc/apt/sources.list

sources.list 添加下面的内容

deb http://mirrors.163.com/ubuntu/ precise main universe restricted multiverse 
deb-src http://mirrors.163.com/ubuntu/ precise main universe restricted multiverse 
deb http://mirrors.163.com/ubuntu/ precise-security universe main multiverse restricted 
deb-src http://mirrors.163.com/ubuntu/ precise-security universe main multiverse restricted 
deb http://mirrors.163.com/ubuntu/ precise-updates universe main multiverse restricted 
deb http://mirrors.163.com/ubuntu/ precise-proposed universe main multiverse restricted 
deb-src http://mirrors.163.com/ubuntu/ precise-proposed universe main multiverse restricted 
deb http://mirrors.163.com/ubuntu/ precise-backports universe main multiverse restricted 
deb-src http://mirrors.163.com/ubuntu/ precise-backports universe main multiverse restricted 
deb-src http://mirrors.163.com/ubuntu/ precise-updates universe main multiverse restricted
apt-get clean
apt-get update
apt-get install percona-xtrabackup-24

全量备份的命令

出现completed OK!说明备份完毕。

innobackupex --user=root --password=a123456 /data/backup/full

PXC 全量恢复步骤

  1. 数据库可以热备份,但是不能热还原。为了避免恢复过程中的数据同步,我们采用空白的mysql还原数据,然后再建立PXC集群的方式。所以在开发中一定要注意权限问题,不要给开发人员root用户。

  2. 还原数据前要将未提交的事务回滚,还原数据之后重启!

  • 执行代码

原来的容器全部删除

docker stop node1 node2 node3 node4 node5
docker rm node1 node2 node3 node4 node5
docker volume rm v1 v2 v3 v4 v5
docker volume create v1

创建node1 和数据卷

docker volume create v1
docker run -d -p 3306:3306  --net=net1 --name=node1 \
        -e CLUSTER_NAME=PXC \
        -e MYSQL_ROOT_PASSWORD=a123456 \
        -e XTRABACKUP_PASSWORD=a123456 \
        -v v1:/var/lib/mysql \
        --privileged \
        --ip 172.18.0.2 \
        -v backup:/data \
        percona/percona-xtradb-cluster

进入容器内还原数据库

#root用户登录
docker exec -it --user root  node1 bash
#删除数据
rm -rf /var/lib/mysql/*
#没有提交的数据回滚
innobackupex --user=root --password=a123456 --apply-back /data/backup/full/2018-12-06_17-18-19/
#执行下冷还原
innobackupex --user=root --password=a123456 --copy-back /data/backup/full/2018-12-06_17-18-19/
chown -R mysql:mysql /var/lib/mysql/

退出容器重启下,node1节点

docker stop node1
docker start node1

PS:数据库的热备份,冷还原也讲完了,真心感觉也不是那么复杂。其实就是这样,但是在云平台越来越盛行的今天,基本上买个rdrs数据库这些功能都有了。









About Me

........................................................................................................................

● 本文作者:小麦苗,部分内容整理自网络,若有侵权请联系小麦苗删除

● 本文在itpub、博客园、CSDN和个人微 信公众号( DB宝)上有同步更新

● 本文itpub地址: http://blog.itpub.net/26736162

● 本文博客园地址: http://www.cnblogs.com/lhrbest

● 本文CSDN地址: https://blog.csdn.net/lihuarongaini

● 本文pdf版、个人简介及小麦苗云盘地址: http://blog.itpub.net/26736162/viewspace-1624453/

● 数据库笔试面试题库及解答: http://blog.itpub.net/26736162/viewspace-2134706/

● DBA宝典今日头条号地址: http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826

........................................................................................................................

● QQ群号: 230161599 、618766405

● 微 信群:可加我微 信,我拉大家进群,非诚勿扰

● 联系我请加QQ好友 646634621 ,注明添加缘由

● 于 2020-04-01 06:00 ~ 2020-04-30 24:00 在西安完成

● 最新修改时间:2020-04-01 06:00 ~ 2020-04-30 24:00

● 文章内容来源于小麦苗的学习笔记,部分整理自网络,若有侵权或不当之处还请谅解

● 版权所有,欢迎分享本文,转载请保留出处

........................................................................................................................

小麦苗的微店https://weidian.com/s/793741433?wfr=c&ifr=shopdetail

小麦苗出版的数据库类丛书http://blog.itpub.net/26736162/viewspace-2142121/

小麦苗OCP、OCM、高可用网络班http://blog.itpub.net/26736162/viewspace-2148098/

小麦苗腾讯课堂主页https://lhr.ke.qq.com/

........................................................................................................................

使用 微 信客户端扫描下面的二维码来关注小麦苗的微 信公众号( DB宝)及QQ群(DBA宝典)、添加小麦苗微 信, 学习最实用的数据库技术。

........................................................................................................................

欢迎与我联系

 

 



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26736162/viewspace-2684413/,如需转载,请注明出处,否则将追究法律责任。

全部评论
【QQ:646634621】【微信:lhrbestxh】【微信公众号:DB宝】【11g、12c OCM】【QQ群:230161599、618766405】【《数据库笔试面试宝典》作者】【OCP、OCM、高可用(RAC+DG+OGG)、MySQL培训班已开讲,只讲实用内容】

注册时间:2012-09-23

  • 博文量
    1494
  • 访问量
    8672569