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高可用：

    待完善