前言

本方案主要目的是学习, 该方案不太合适于企业项目

是什么?

白话点, 是个提供了必要环境的虚拟机(类似于java的导入部分包一样和c++的头文件差不多), 所以它比普通的VMWare或者VirtualBox安装的虚拟机要

总体来说类似于jvm那样的存在, 只不过jvm运行的是java编译的字节码, docker运行的是各种组件, 比如mysql, redis, zookeeper或者我们的项目

有哪些关键的概念

  1. 镜像

docker镜像类似于系统安装包ISO, 或者我们对某个程序的备份, 将这个备份压缩成rar压缩包, 备份了很多程序的数据和配置, 我们只要把这个压缩包丢给别人, 别人解压并使用这个程序

  1. 容器

容器类似于我们的程序(前面的镜像是压缩包), 可以直接运行

总结

镜像和容器的关系是 一个镜像对应可以多个容器(只要你创建的多)

怎么用?

设置镜像加速

创建或编辑该文件:

vi /etc/docker/daemon.json

在该文件中输入如下内容:

{
"registry-mirrors": [
"https://docker.mirrors.ustc.edu.cn",
"https://hub-mirror.c.163.com",
"https://mirror.ccs.tencentyun.com",
"https://registry.docker-cn.com"
]
}

docker基本指令

service docker start # 开启docker
service docker stop # 关闭docker
service docker restart # 重启docker

镜像管理

导入导出镜像

docker save java > /home/java.tar.gz
docker load < /home/java.tar.gz

镜像查找

docker search java

镜像下载

docker pull java

查看镜像列表

docker images

查看镜像信息

docker inspect java
[
{
"Id": "sha256:d23bdf5b1b1b1afce5f1d0fd33e7ed8afbc084b594b9ccf742a5b27080d8a4a8",
"RepoTags": [
"java:latest"
],
"RepoDigests": [
"java@sha256:c1ff613e8ba25833d2e1940da0940c3824f03f802c449f3d1815a66b7f8c0e9d"
],
"Parent": "",
"Comment": "",
"Created": "2017-01-17T00:52:54.890877145Z",
"Container": "4b4ab1e131616e04a88f26f9811e5847dd0c3ec5f8178b634b388d3c510ee606",
"ContainerConfig": {
"Hostname": "33842653d6db",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"LANG=C.UTF-8",
"JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64",
"JAVA_VERSION=8u111",
"JAVA_DEBIAN_VERSION=8u111-b14-2~bpo8+1",
"CA_CERTIFICATES_JAVA_VERSION=20140324"
],
"Cmd": [
"/bin/sh",
"-c",
"/var/lib/dpkg/info/ca-certificates-java.postinst configure"
],
"ArgsEscaped": true,
"Image": "sha256:7cfe1ce37b990ea20d6377b8901f5ffccd463ed2f965e9730d834e693b53baec",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": null,
"OnBuild": [],
"Labels": {}
},
"DockerVersion": "1.12.3",
"Author": "",
"Config": {
"Hostname": "33842653d6db",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"LANG=C.UTF-8",
"JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64",
"JAVA_VERSION=8u111",
"JAVA_DEBIAN_VERSION=8u111-b14-2~bpo8+1",
"CA_CERTIFICATES_JAVA_VERSION=20140324"
],
"Cmd": [
"/bin/bash"
],
"ArgsEscaped": true,
"Image": "sha256:7cfe1ce37b990ea20d6377b8901f5ffccd463ed2f965e9730d834e693b53baec",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": null,
"OnBuild": [],
"Labels": {}
},
"Architecture": "amd64",
"Os": "linux",
"Size": 643195347,
"VirtualSize": 643195347,
"GraphDriver": {
"Data": {
"LowerDir": "/var/lib/docker/overlay2/fcdfe412499e0b1afe9cb8d6800eb56af9c578b1c49fbf0fc9f38fead4f32b2d/diff:/var/lib/docker/overlay2/5d79e6646df2342376ba59d8d21b70142d0e3fd0c9a0de2229c1cfa4c2d98e93/diff:/var/lib/docker/overlay2/47b9afdc585a2c847d112283d7d884f00140dab44c33203eeeccc4a592a23378/diff:/var/lib/docker/overlay2/9565b7df775e50948f7713b8a1b1ba6610eb055c958bbd23a7646b4414ccefab/diff:/var/lib/docker/overlay2/dd8233c055d2241a6e52a0f0acd48220f87a75e50fbe2a7355445bcc75bbfbb9/diff:/var/lib/docker/overlay2/64bb2d108355eb53a495cdb6804e602baa651888a27c10c19dfb0fa2351648b6/diff:/var/lib/docker/overlay2/3fb4d1d79e7b1966b16dfb4d7dcde2ac6ac602f932395acf2c5d3bd0573a9c67/diff",
"MergedDir": "/var/lib/docker/overlay2/09e28e456caf00dd0ab82af1f594f248f05e0e64a4b931f69251ab2f1c9c4df3/merged",
"UpperDir": "/var/lib/docker/overlay2/09e28e456caf00dd0ab82af1f594f248f05e0e64a4b931f69251ab2f1c9c4df3/diff",
"WorkDir": "/var/lib/docker/overlay2/09e28e456caf00dd0ab82af1f594f248f05e0e64a4b931f69251ab2f1c9c4df3/work"
},
"Name": "overlay2"
},
"RootFS": {
"Type": "layers",
"Layers": [
"sha256:a2ae92ffcd29f7ededa0320f4a4fd709a723beae9a4e681696874932db7aee2c",
"sha256:0eb22bfb707db44a8e5ba46a21b2ac59c83dfa946228f04be511aba313bdc090",
"sha256:30339f20ced009fc394410ac3360f387351641ed40d6b2a44b0d39098e2e2c40",
"sha256:ce6c8756685b2bff514e0b28f78eedb671380084555af2b3833e54bb191b262a",
"sha256:a3483ce177ce1278dd26f992b7c0cfe8b8175dd45bc28fee2628ff2cf063604c",
"sha256:6ed1a81ba5b6811a62563b80ea12a405ed442a297574de7440beeafe8512a00a",
"sha256:c3fe59dd955634c3fa1808b8053353f03f4399d9d071be015fdfb98b3e105709",
"sha256:35c20f26d18852b74cc90afc4fb1995f1af45537a857eef042a227bd8d0822a3"
]
},
"Metadata": {
"LastTagTime": "0001-01-01T00:00:00Z"
}
}
]

镜像删除

docker rmi java

容器管理

启动镜像(镜像初次产生容器)

启动镜像会默认创建出一个容器

  • docker run -it --name myjava java bash 使用bash运行保持控制台方式运行
  • docker run -it --name myjava -p 9000:8080 -p 9050:8050 java bash 以控制台方式运行java并且映射了java的端口8080到主机的9000, 映射到java的8050到主机的9050端口
  • docker run -it -name myjava -v /home/project:/soft --privileged java bash 映射java应用的路径/soft 到主机的/home/project路径并使用--privileged给了修改权限
mkdir /home/project
docker run -it --name myjava -p 9000:8080 -p 9050:8050 -v /home/project:/soft --privileged java bash

添加[option] -d创建和以后台方式启动容器

暂停、停止和开启容器

docker pause myjava # 可以在另一个控制台暂停
docker unpause myjava # 可以在另一个控制台执行
docker stop myjava # 可以停止掉容器
docker start -i myjava

查看容器和查看运行中的容器

docker ps -a # 查看所有容器, 包括未运行的容器
docker ps # 查看正在运行的容器

删除容器

docker rm myjava 删除容器

创建docker内部网络

创建docker内部网络比较安全, 内部只要对外部提供端口便可, 一般用于集群内部网络时使用

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 容器的文件系统在宿主机上存在的方式很复杂,这会带来下面几个问题:

  • 不能在宿主机上很方便地访问容器中的文件。
  • 无法在多个容器之间共享数据。
  • 当容器删除时,容器中产生的数据将丢失。

为了解决这些问题,docker 引入了数据卷(volume) 机制。数据卷是存在于一个或多个容器中的特定文件或文件夹,这个文件或文件夹以独立于 docker 文件系统的形式存在于宿主机中。数据卷的最大特定是:其生存周期独立于容器的生存周期。

使用数据卷的最佳场景

  • 在多个容器之间共享数据,多个容器可以同时以只读或者读写的方式挂载同一个数据卷,从而共享数据卷中的数据。
  • 当宿主机不能保证一定存在某个目录或一些固定路径的文件时,使用数据卷可以规避这种限制带来的问题。
  • 当你想把容器中的数据存储在宿主机之外的地方时,比如远程主机上或云存储上。
  • 当你需要把容器数据在不同的宿主机之间备份、恢复或迁移时,数据卷是很好的选择。

使用方法

docker volume create --name v1

例如:

root@ubuntu:/# docker volume create --name node1
node1
root@ubuntu:/# docker volume inspect node1
[
{
"CreatedAt": "2020-07-08T14:03:16+08:00",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/node1/_data",
"Name": "node1",
"Options": {},
"Scope": "local"
}
]

它把卷创建到了宿主机的/var/lib/docker/volumes/node1/_data目录下

搭建MySql集群(PXC方案: 不建议选择这套方案)

下载pxc

docker pull percona/percona-xtradb-cluster:5.7

图片中笔者本来想配置mysql8.0的pxc方案, 但主机的ssl配置成功后,从机的ssl一直验证不通过(笔者给予了几个文件足够的权限777). 主机ssl的几个文件必须是读写执行权限全给才能够验证成功, 但从机的custom.cnf权限如果还是读写执行权限将会被忽略, 所以笔者创建了两个config文件夹, 里面存了两个custom.cnf配置文件, 只有权限不同, 虽然这个配置文件不再被忽略, 但还是不行, 会不断的重复尝试连接ssl//:172.18.0.2:4567, 没辙. 只能回到5.7的怀抱

docker搭建mysql8.0的pxc方案相关资料

创建docker内部网络

docker network create --subnet=172.18.0.0/24 pxc_net1

创建docker卷

docker volume create v1
docker volume create v2
docker volume create v3
docker volume create v4
docker volume create v5
docker volume create backup

创建集群

  • 创建主机
docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=pxc -e XTRABACKUP_PASSWORD=123456 -v v1:/var/lib/mysql -v backup:/data --privileged --name pxc_node1 --net=pxc_net1 --ip=172.18.0.2 percona/percona-xtradb-cluster:5.7
  • 创建从机

集群这几个地方要改

docker run -d -p 3307:3306 -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=pxc -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pxc_node1 -v v2:/var/lib/mysql -v backup:/data --privileged --name pxc_node2 --net=pxc_net1 --ip=172.18.0.3 percona/percona-xtradb-cluster:5.7

docker run -d -p 3307:3306 -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=pxc -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pxc_node1 -v v2:/var/lib/mysql -v backup:/data --privileged --name pxc_node2 --net=pxc_net1 --ip=172.18.0.3 percona/percona-xtradb-cluster:5.7

docker run -d -p 3308:3306 -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=pxc -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pxc_node1 -v v3:/var/lib/mysql -v backup:/data --privileged --name pxc_node3 --net=pxc_net1 --ip=172.18.0.4 percona/percona-xtradb-cluster:5.7

docker run -d -p 3309:3306 -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=pxc -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pxc_node1 -v v4:/var/lib/mysql -v backup:/data --privileged --name pxc_node4 --net=pxc_net1 --ip=172.18.0.5 percona/percona-xtradb-cluster:5.7

docker run -d -p 3310:3306 -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=pxc -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pxc_node1 -v v5:/var/lib/mysql -v backup:/data --privileged --name pxc_node5 --net=pxc_net1 --ip=172.18.0.6 percona/percona-xtradb-cluster:5.7

使用Haproxy负载均衡

docker pull haproxy

mkdir ~/docker/haproxy
cd ~/docker/haproxy
vi 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:123456
#数据库负载均衡
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数据库心跳检测
# CREATE USER 'haproxy'@'%' IDENTIFIED by ''; FLUSH PRIVILEGES;
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 run -it -d -p 4001:8888 -p 4002:3306 -v /root/docker/haproxy:/usr/local/etc/haproxy --name h1 --net=pxc_net1 --ip 172.18.0.8 --privileged haproxy

docker run -it -d -p 4003:8888 -p 4004:3306 -v /root/docker/haproxy:/usr/local/etc/haproxy --name h2 --net pxc_net1 --ip 172.18.0.9 --privileged haproxy

记住这句上面注释掉的CREATE USER 'haproxy'@'%' IDENTIFIED by ''; FLUSH PRIVILEGES; 这句话如果不在数据库中创建好用户, 将会在出现Haproxy无法感知mysql是否启动的情况, 因为她需要通过数据库创建的这个账号haproxy监控数据库情况(所以你可以不给这个账号任何权限, 只要他们访问就行)

所以docker exec -it pxc_node1 /usr/bin/mysql -uroot -p123456进入容器, 然后复制CREATE USER 'haproxy'@'%' IDENTIFIED by ''; FLUSH PRIVILEGES;去创建这个账户

只要在一个节点创建就好, 其他数据库会同步更新

进入docker中的haproxy控制台中

docker exec -it h1 bash

加载配置文件haproxy -f /usr/local/etc/haproxy/haproxy.cfg

之后访问

http://192.168.0.135:4001/dbs

至此配置haproxy配置完成了, 我们使用navicat连接下试试

cf014fbc9ef7        haproxy                              "/docker-entrypoint.…"   2 hours ago         Up 2 hours          0.0.0.0:4002->3306/tcp, 0.0.0.0:4001->8888/tcp   h1

我是尝试连接下

4002端口

现在我们尝试下关闭掉数据库节点pxc_node1

docker stop pxc_node1

我们新建完毕

这里我们其他库都更新完毕了, 但pxc_node1是空的

我们现在重新开启pxc_node1节点看下, 是不是那个表被添加到这个节点了

发现无法开启这个节点了(这是怎么回事???)

vi /var/lib/docker/volumes/v1/_data/grastate.dat 修改

safe_to_bootstrap: 0safe_to_bootstrap: 1

再次尝试启动这个节点

虽然成功了, 但是数据没被同步过去

甚至还会出现这个问题(因为是轮训, 所以随机出现无法找到数据库问题)

现在我们尝试修改下, 别的数据库中的数据(非pxc_node1数据库节点)

这数据就这么丢了

现在我们重启docker, 然后在依次重新启动节点

配置数据库双机热备

为什么需要双机热备???

单个Haproxy节点不具备高可用, 必须要给个备机防止主机没了, 导致我们的服务无法访问的问题

linux提供了虚拟IP的技术, 我们的双机热备需要利用它(虚拟ip就是在一个网卡上可以对不同的程序提供不同的虚拟ip)

使用keepalived方式以抢占虚拟IP的方式完成, 所以我们需要在docker haproxy内部配置环境

完整方案

安装keepalived

  • Keepalived必须要安装在Haproxy所在的容器之内
apt-get update
apt-get upgrade
apt install keepalived
  • keepalived配置文件

Keepalived的配置文件是/etc/keepalived/keepalived.conf

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
}
}

启动keepalived

serivce keepalived start 启动它

以上操作都在docker容器中操作

然后我们测试下主机是否能够ping通docker内部的网络下的虚拟机

ping 172.18.0.201

  • 另一个docker中的keepalived配置
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.202
}
}

serivce keepalived start 启动它

退出回到宿主机, ping 172.18.0.202看下是否能够ping的通

  • 宿主机安装keepalived

vi /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
state MASTER
interface ens33
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.0.155
}
} virtual_server 192.168.0.155 8888 {
delay_loop 6
lb_algo rr
lb_kind NAT
persistence_timeout 50
protocol TCP real_server 172.18.0.201 8888 {
weight 1
}
real_server 172.18.0.202 8888 {
weight 1
}
} virtual_server 192.168.0.155 3306 {
delay_loop 6
lb_algo rr
lb_kind NAT
persistence_timeout 50
protocol TCP real_server 172.18.0.201 3306 {
weight 1
}
real_server 172.18.0.202 3306 {
weight 1
}
}

启动keepalived, systemctl start keepalived(宿主机是centOS7, 所以使用systemctl)

再ping下ping 192.168.0.155

[root@centOS ~]# ping 192.168.0.155
PING 192.168.0.155 (192.168.0.155) 56(84) bytes of data.
From 192.168.0.144 icmp_seq=1 Destination Host Unreachable
From 192.168.0.144 icmp_seq=2 Destination Host Unreachable
From 192.168.0.144 icmp_seq=3 Destination Host Unreachable
From 192.168.0.144 icmp_seq=4 Destination Host Unreachable
^C
--- 192.168.0.155 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3000ms
pipe 4
[root@centOS ~]# ping 192.168.0.155
PING 192.168.0.155 (192.168.0.155) 56(84) bytes of data.
64 bytes from 192.168.0.155: icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from 192.168.0.155: icmp_seq=2 ttl=64 time=0.048 ms
64 bytes from 192.168.0.155: icmp_seq=3 ttl=64 time=0.039 ms
^C

注意下: keepalived的启动需要一点点时间, 上面控制台输出Destination Host Unreachable是因为压根没启动完毕

我们回到真正的主机(window上)在ping下, 看下行不行

ping 192.168.0.155

正在 Ping 192.168.0.155 具有 32 字节的数据:
来自 192.168.0.155 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.0.155 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.0.155 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.0.155 的回复: 字节=32 时间<1ms TTL=64 192.168.0.155 的 Ping 统计信息:
数据包: 已发送 = 4,已接收 = 4,丢失 = 0 (0% 丢失),
往返行程的估计时间(以毫秒为单位):
最短 = 0ms,最长 = 0ms,平均 = 0ms

ok, 配置完成

我们在navicat上连接下

ip: 192.168.0.155
用户: root
密码: 123456(我为了简便设置了简单的密码, 实际项目中千万别这么简单)
端口: 3306

完成

  • 但存在一个问题, 每次启动docker, 都要进入docker h1和h2容器中再启动keepalived, 挺麻烦的, 放心后面会慢慢解决的
  • 还存在一个问题, 用户无法知道keepalived哪些节点能用, 哪些节点不能用了

    keepalived容易出现脑裂, 所以我也不太推荐使用这种方案, 本方案主要目的是学习

热备方案

冷备份和热备份之间的关系是会不会实际影响到我们的业务(锁住备份区域,或者干脆阻塞它), 冷备会, 热备份不会, 显而易见, 选热备

而热备方案中又有全量备份增量备份物理备份

真的是, 各种名词看腻了, 说白了就是一次备份是不是直接 copy 还是 copy + 1 这样的不断备份, 还有一种就是忽略了文件系统结构的备份

我们选择xtrabackup做热备方案

还记得前面我在创建集群时加的参数么? -v backup:/data这个, 现在我们要将数据库备份映射到这个目录, 如果前面创建集群时, 没有增加这个参数需要stop后删除的重新创建

如果我们没有添加映射备份目录, 那么需要

docker stop pxc_node1
docker rm pxc_node1
docker run -d -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=pxc -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pxc_node2 --net=pxc_net1 --ip=172.18.0.2 -p 3306:3306 -v v1:/var/lib/mysql -v backup:/data --privileged --name pxc_node1 percona/percona-xtradb-cluster:5.7

现在我们进入docker容器中的pxc_node1节点

看看这个容器运行的系统是什么版本的linux系统

red hat 或者 centOS 系统所以我们需要使用yum去更新

docker exec -it pxc_node1 bash

bash-4.2$ yum update
Loaded plugins: fastestmirror, ovl
ovl: Error while doing RPMdb copy-up:
[Errno 13] Permission denied: '/var/lib/rpm/.dbenv.lock'
You need to be root to perform this command.

exit退出, 然后docker exec -it --user root pxc_node1 bash or docker exec -it --user=root pxc_node1 bash

yum clean all
yum makecache
yum update
yum install wget
wget https://repo.percona.com/yum/percona-release-latest.noarch.rpm
rpm -ivh percona-release-latest.noarch.rpm
rm percona-release-latest.noarch.rpm
yum list | grep percona

进行一次全量热备

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

回到宿主机, 看看

docker volume inspect backup

cd /var/lib/docker/volumes/backup/_data

就可以看到已经备份了

所有的pxc_node* 节点都是共享的 backup 目录

还原也一样

docker exec -it pxc_node1 bash # 进入节点
rm -rf /var/lib/mysql/* # 删除掉原本的数据
# 将还没有提交的事务回滚
innobackupex --user=root --password=lezhu123456 --apply-back /data/backup/full/2018-04-15_05-09-07/
# 恢复
innobackupex --user=root --password=lezhu123456 --copy-back /data/backup/full/2018-04-15_05-09-07/

不是我说, 有更好的选择千万别选pxc

待续...

docker搭建数据库高可用方案PXC的更多相关文章

  1. MySQL MGR+ Consul之数据库高可用方案

    背景说明:     基于目前存在很多MySQL数据库单点故障,传统的MHA,PXC等方案用VIP或者DNS切换的方式可以实现.基于数据库的数据强一致性考虑,采用MGR集群,采用consul服务注册发现 ...

  2. MYSQL数据库高可用方案探究

    MySQL作为最关键的应用数据存储中心,如何保证MySQL服务的可靠性和持续性,是我们不得不细致考虑的一个问题.当master宕机的时候,我们如何保证数据尽可能的不丢失,如何保证快速的获知master ...

  3. MySQL数据库高可用方案

    一.什么是高可用性: 高可用性=可靠性,它的本质就是通过技术和工具提高可靠性,尽可能长时间保持数据可用和系统运行,实现高可用性的原则,首先要消除单点故障,其次通过冗余机制实现快速恢复,还有就是实现容错 ...

  4. MySQL 同步复制及高可用方案总结

    1.前言 mysql作为应用程序的数据存储服务,要实现mysql数据库的高可用.必然要使用的技术就是数据库的复制,如果主节点出现故障可以手动的切换应用到从节点,这点相信运维同学都是知道,并且可以实现的 ...

  5. 利用ansible书写playbook搭建HAProxy+Keepalived+PXC负载均衡和高可用的PXC环境续

    ansible.playbook.haproxy.keepalived.PXC haproxy+keepalived双主模式调度pxc集群 HAProxy介绍 反向代理服务器,支持双机热备支持虚拟主机 ...

  6. MySQL高可用方案-PXC(Percona XtraDB Cluster)环境部署详解

    MySQL高可用方案-PXC(Percona XtraDB Cluster)环境部署详解 Percona XtraDB Cluster简称PXC.Percona Xtradb Cluster的实现是在 ...

  7. MySQL高可用方案-PXC环境部署记录

    之前梳理了Mysql+Keepalived双主热备高可用操作记录,对于mysql高可用方案,经常用到的的主要有下面三种: 一.基于主从复制的高可用方案:双节点主从 + keepalived 一般来说, ...

  8. MySQL数据库的高可用方案总结

    高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用.虽然互联网服务号称7*24小时不间断服务,但多多少少有一些时候服务不可用,比如某些时候网页打不开,百度不能搜索或者无法 ...

  9. (转载)MySQL数据库的几种常见高可用方案

    转自: https://yq.aliyun.com/articles/74454   随着人们对数据一致性的要求不断的提高,越来越多的方法被尝试用来解决分布式数据一致性的问题,如MySQL自身的优化. ...

随机推荐

  1. logstash数据处理及格式化功能详解

    Grok正则提取日志 环境延续我上一篇ELK单机版的filebeat-->redis-->logstash-->elasticsearch-->kibana环境,详情请参考: ...

  2. mysql3_pymysql

    python数据库编程 1.pyshon数据库接口(python DB-API) 1.为开发人员提供的数据库应用编程接口 2.python支持的数据库服务软件 mysql,oracle,sql_ser ...

  3. 结合JVM 浅谈Java 类加载器(Day_03)

    所谓错过,不是错了,而是过了. 什么是JAVA类加载? Class对象由JVM自动产生,每当一个类被加载时,JVM就自动为其生成一个Class对象,通过Class对象可以获得类的相关信息.将类信息读取 ...

  4. Linux(CentOS 7) 安全加固之非业务端口服务关闭 postfix port 25

    目录 关闭TCP 25 端口对应的服务 1. 确认对应端口的进程 2. 查找与关闭对应服务 3. 确认结果,端口已关闭 关闭TCP 25 端口对应的服务 [0 root@Qvps /root] #ca ...

  5. SPI接口在LCD上的应用

    ​小分辨率的LCD,比如QQVGA,QCIF,QVGA等,广泛应用于功能手机和穿戴设备(比如手表)上.这类小分辨率的LCD,除了支持并行接口(比如i80),一般也会支持串行接口.在实际产品中广泛运用的 ...

  6. Python小白的数学建模课-A1.2021年数维杯C题(运动会优化比赛模式探索)探讨

    Python小白的数学建模课 A1-2021年数维杯C题(运动会优化比赛模式探索)探讨. 运动会优化比赛模式问题,是公平分配问题 『Python小白的数学建模课 @ Youcans』带你从数模小白成为 ...

  7. YOLOv5目标检测源码重磅发布了!

    YOLOv5目标检测源码重磅发布了! https://github.com/ultralytics/yolov5 该存储库代表了对未来对象检测方法的超解析开源研究,并结合了在使用之前的YOLO存储库在 ...

  8. GPU虚拟化技术详解

    GPU虚拟化技术详解 GPU英文名称为Graphic Processing Unit,GPU中文全称为计算机图形处理器,1999年由NVIDIA公司提出. 一.GPU概述 GPU这一概念也是相对于计算 ...

  9. GStreamer 1.0 series序列示例

    GStreamer 1.0 series序列示例 OpenEmbedded layer for GStreamer 1.0 这layer层为GStreamer 1.0框架提供了非官方的支持,用于Ope ...

  10. 目标检测数据集The Object Detection Dataset

    目标检测数据集The Object Detection Dataset 在目标检测领域,没有像MNIST或Fashion MNIST这样的小数据集.为了快速测试模型,我们将组装一个小数据集.首先,我们 ...