pxc集群与haproxy负载以及使用keepalived实现高可用And使用shardingJdbc搭配druid实现分区分表遇到的坑

搭建pxc集群：

    1,安装pxc镜像：docker pull percona/percona-xtradb-cluster 
    2,建立虚拟网段：docker network create --subnet=172.18.0.0/24 net1   查看：docker network inspect net1 删除：docker network rm net1
    3,建立docker卷（直接映射宿主机路径会致使pxc闪退）：docker volume create --name v1  查看：docker volume inspect v1 删除：docker volume rm v1
    4,建立pxc容器：
    db1: docker run -d -p 3307:3306 -v v1:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=abc123456 -e CLUSTER_NAME=PXC -e XTRABACKUP_PASSWORD=adc123456 --privileged --name=node1 --net=net1 --ip 172.18.0.2 pxc
    db2: docker run -d -p 3308:3306 -v v2:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=abc123456 -e CLUSTER_JOIN=node1 -e CLUSTER_NAME=PXC -e XTRABACKUP_PASSWORD=adc123456 --privileged --name=node2 --net=net1 --ip 172.18.0.3 pxc
    db3: docker run -d -p 3309:3306 -v v3:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=abc123456 -e CLUSTER_JOIN=node1 -e CLUSTER_NAME=PXC -e XTRABACKUP_PASSWORD=adc123456 --privileged --name=node3 --net=net1 --ip 172.18.0.4 pxc
    
    问题1：全部节点同时挂掉或者物理宿主机宕机致使节点所有挂掉的状况，再次重启各类闪退？
        找到任意docker卷目录，查看grastate.dat文件，里面有个参数safe_to_bootstrap它的值记录了pxc集群最后一个退出的节点，那么重启只需先启动该节点再启动其余节点便可
    问题2：当主节点node1挂掉后，再次重启过几秒以后node1会自动挂掉，其余节点无此状况？
        由node1的启动参数可知，node1再启动时尝试建立pxc集群，此时其余节点正在pxc集群组内，建立一个同名pxc集群必然会报错，解决方法，删除node1容器，可是不要删除v1数据卷，再修改node1启动参数
        把node1当作从节点启动，加入pxc集群组，随便加入一个已存在节点便可正常使用

使用Haproxy实现pxc集群的负载均衡

    1,安装Haproxy镜像：docker pull haproxy
    2,在宿主机上建立Haproxy配置文件: touch /software/haproxy/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:admin
    #数据库负载均衡
    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 
        #使用keepalive检测死链
        option  tcpka  

    3,建立haproxy容器: docker run -d -p 3308:3306 -v v2:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=abc123456 -e CLUSTER_JOIN=node1 -e     CLUSTER_NAME=PXC -e XTRABACKUP_PASSWORD=adc123456 --privileged --name=node2 --net=net1 --ip 172.18.0.3 pxc
    4,进入h1容器：docker exec -it h1 bash
    5,按配置文件启动haproxy: haproxy -f /usr/local/etc/haproxy/haproxy.cfg 
    6,在pxc集群数据库内建立用户名为haproxy的用户，密码为空（重点）

使用sharding-jdbc实现数据库分区分表

    网上大部分sharding-jdbc配置均为sharding2版本配置，官方推荐配置是基于sharding3版本配置，二者有些许配置差异，建议结合sharding源码修改配置冲突部分已引入sharing版本源码为准，下述内容基于io.shardingjdbc.sharding-jdbc-core.2.0.3版本
    
    maven依赖：
    <dependency>
        <groupId>io.shardingjdbc</groupId>
        <artifactId>sharding-jdbc-core</artifactId>
        <version>2.0.3</version>
    </dependency>
    
    配置：采用yaml文件配置，在resources目录下建立sharding-jdbc.yml文件
    

dataSources:
  zgyw: !!com.alibaba.druid.pool.DruidDataSource
    driverClassName: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://192.168.101.89:4002/zgyw?characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: abc123456

shardingRule:
  tables:
    variable_value:
      actualDataNodes: zgyw.variable_value_20190${1..9}
      tableStrategy:
        standard: # 单列sharidng算法,须要配合对应的preciseShardingAlgorithm,rangeShardingAlgorithm接口的实现使用,目前无生产可用实现
          shardingColumn: create_time # 列名,容许单列
          preciseAlgorithmClassName: com.zgyw.equipment.config.MyShardingConfig # preciseShardingAlgorithm接口的实现类，用于 `=` and `IN` 状况下的分表算法
#          rangeAlgorithmClassName: # rangeShardingAlgorithm接口的实现类，用于 `BETWEEN` 状况下的分表算法
      keyGeneratorColumnName: id
      keyGeneratorClass: com.zgyw.equipment.keyGenerator.CommonIdKeyGenerator

  bindingTables:
    - variable_value

    分表逻辑自定义类：分表逻辑tableStrategy能够指定分表逻辑类进行自定义逻辑实现，配置preciseAlgorithmClassName指定自定义分表逻辑类，该类需实现PreciseShardingAlgorithm

    接口主键策略问题：能够默认使用sharing提供的主键策略如：defaultKeyGenerator: type: SNOWFLAKE 也能够指定自定义策略类实现keyGeneratorClass，该类需实现KeyGenerator接口
    主从问题：误区所在！主从数据源或多数据源配置 != 数据库集群

    数据库集群实现方案为keepalived+haproxy+pxc实现。暴露至项目为一个keepalived抢占获得的虚拟IP，从项目的角度来看能够看作单数据源，至于底层pxc组内节点库中数据高度一致，而多数据源配置或者说主从数据库源配置，各个数据源内部数据不须要保持一致，可在项目中经过一系列配置控制相关业务逻辑分库存储，这2个概念没弄清致使一度怀疑sharding源码实现有问题，由于只要是配置在配置文件中的数据源，任意数据源挂掉会致使项目没法正常运行，这和集群的概念是彻底背离的！

使用druid管理数据库链接池

    <dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>druid</artifactId>
        <version>1.1.18</version>
    </dependency>
    Druid是阿里巴巴开发的号称为监控而生的数据库链接池，是目前最好用的数据库链接池，可监控数据库访问性能，查看SQL执行日志，经过druid的Filter机制更方面的编写JDBC层扩展插件，具
    体配置参阅网上配置说明
    springboot项目配置多数据源；经过配置文件动态切换数据源，可在不一样业务逻辑处经过自定义注解控制操做不一样数据源，具体配置不细说

使用keepalive实现haproxy高可用：

    待完善