主頁 > 資料庫 > MySQL高可用架構之MHA

MySQL高可用架構之MHA

2020-09-22 22:40:21 資料庫

該文章轉自: https://www.cloudbility.com/club/7104.html

 

目錄

  •  一、當前高可用方案
    • 1、Heartbeat+DRBD
    • 2、MySQL Cluster
    • 3、全域事務ID
    • 4、PXC
    • 5、MHA的優勢
      • 1)故障切換快
      • 2)master故障不會導致資料不一致
      • 3)無需修改當前的MySQL設定
      • 4)無需增加大量的服務器
      • 5)無性能下降
      • 6)適用于任何存盤引擎
  • 二、MHA簡介:
    • 1、MHA結構
      • 1)MHA Manager
        • 1.Manager工具包主要工具
      • 2)MHA Node
        • 1.Node工具包
      • 3)注意
    • 2、MAH作業原理
  • 三、部署MHA
    • 1、環境準備
    • 2、安裝epel源
    • 3、環境初始化
      • 1)修改每臺主機名
      • 2)主機名決議
      • 3)ssh無密碼登錄
  • 四、規劃mysql
    • 1)安裝mysql
    • 2)配置master、slave01和slave02之間的主從復制
    • 3)在master、slave01上創建主從同步的賬號,
    • 4)在master上執行命令,查看master狀態資訊
    • 5)在slave01和slave02上執行主從同步
  • 五、規劃mha
    • 1)創建mha管理用的復制賬號
    • 2)在3臺主機上(master、slave01和slave02)上分別安裝mha4mysql-node包
    • 3)在manager上安裝mha4mysql-manager和mha4mysql-node包
    • 4)修改manager端mha的組態檔
    • 5)檢查ssh是否暢通
    • 6)masterha_check_repl工具檢查mysql主從復制是否成功
  • 六、mha實驗模擬
    • 1)在每次做mha實驗的時候,我們都最好先執行如下命令做檢測
    • 2)在manager端啟動mha服務并時刻監控日志檔案的輸出變化
    • 3)測驗master宕機后會自動切換
    • 4)恢復master服務
    • 5)再次啟動MHA的manager服務,并停止slave01
    • 6)恢復slave01服務
    • 7)重啟MHA的manager服務
  • 七、通過vip實作mysql的高可用
    • 1)修改/usr/local/mha/mha.cnf
    • 2)修改腳本/usr/local/mha/scripts/master_ip_failover
    • 3)模擬故障進行切換
  • 八、MHA日常維護命令
    • 1、查看ssh登陸是否成功
    • 2、查看復制是否建立好
    • 3、啟動mha
    • 4、檢查啟動的狀態
    • 5、停止mha
    • 6、failover后下次重啟
  • 九、FAQ(常見問題解答)
    • 1、可能報錯1
    • 2、可能報錯2
    • 3、可能報錯3
    • 4、可能報錯4
    • 5、可能報錯5
    • 6、小知識
    • 一、當前高可用方案

      1、Heartbeat+DRBD

      開銷:需要額外添加處于被動狀態的master server(并不處理應用流量) 性能:為了實作DRBD復制環境的高可用,innodb-flush-log-at-trx-commit和sync-binlog必須設定為1,這樣會導致寫性能下降,

      一致性:在master上必要的binlog時間可能會丟失,這樣slave就無法進行復制,導致產生資料一致性問題,

      2、MySQL Cluster

      MySQL Cluster真正實作了高可用,但是使用的是NDB存盤引擎,并且SQL節點有單點故障問題,

      半同步復制(5.5+) 半同步復制大大減少了“binlog events只存在故障master上”的問題,

      在提交時,保證至少一個slave(并不是所有的)接收到binlog,因此一些slave可能沒有接收到binlog,

      3、全域事務ID

      在二進制檔案中添加全域事務ID(global transaction id)需要更改binlog格式,在5.1/5.5版本中不支持,

      在應用方面有很多方法可以直線全域事務ID,但是仍避免不了復雜度、性能、資料丟失或者一致性的問題,

      4、PXC

      PXC實作了服務高可用,資料同步時是并發復制,但是僅支持InnoDB引擎,所有的表都要有主鍵,鎖沖突、死鎖問題相對較多等等問題,

      5、MHA的優勢

      1)故障切換快

      在主從復制集群中,只要從庫在復制上沒有延遲,MHA通常可以在數秒內實作故障切換,9-10秒內檢查到master故障,可以選擇在7-10秒關閉master以避免出現裂腦,幾秒鐘內,將差異中繼日志(relay log)應用到新的master上,因此總的宕機時間通常為10-30秒,恢復新的master后,MHA并行的恢復其余的slave,即使在有數萬臺slave,也不會影響master的恢復時間,

      2)master故障不會導致資料不一致

      當目前的master出現故障是,MHA自動識別slave之間中繼日志(relay log)的不同,并應用到所有的slave中,這樣所有的salve能夠保持同步,只要所有的slave處于存活狀態,和Semi-Synchronous Replication一起使用,(幾乎)可以保證沒有資料丟失,

      3)無需修改當前的MySQL設定

      MHA的設計的重要原則之一就是盡可能地簡單易用,MHA作業在傳統的MySQL版本5.0和之后版本的主從復制環境中,和其它高可用解決方法比,MHA并不需要改變MySQL的部署環境,MHA適用于異步和半同步的主從復制,

      啟動/停止/升級/降級/安裝/卸載MHA不需要改變(包擴啟動/停止)MySQL復制,當需要升級MHA到新的版本,不需要停止MySQL,僅僅替換到新版本的MHA,然后重啟MHA Manager就好了,

      MHA運行在MySQL 5.0開始的原生版本上,一些其它的MySQL高可用解決方案需要特定的版本(比如MySQL集群、帶全域事務ID的MySQL等等),但并不僅僅為了master的高可用才遷移應用的,在大多數情況下,已經部署了比較舊MySQL應用,并且不想僅僅為了實作Master的高可用,花太多的時間遷移到不同的存盤引擎或更新的前沿發行版,MHA作業的包括5.0/5.1/5.5的原生版本的MySQL上,所以并不需要遷移,

      4)無需增加大量的服務器

      MHA由MHA Manager和MHA Node組成,

      MHA Node運行在需要故障切換/恢復的MySQL服務器上,因此并不需要額外增加服務器,

      MHA Manager運行在特定的服務器上,因此需要增加一臺(實作高可用需要2臺),但是MHA Manager可以監控大量(甚至上百臺)單獨的master,因此,并不需要增加大量的服務器,即使在一臺slave上運行MHA Manager也是可以的,綜上,實作MHA并沒用額外增加大量的服務,

      5)無性能下降

      MHA適用與異步或半同步的MySQL復制,監控master時,MHA僅僅是每隔幾秒(默認是3秒)發送一個ping包,并不發送重查詢,可以得到像原生MySQL復制一樣快的性能,

      6)適用于任何存盤引擎

      MHA可以運行在只要MySQL復制運行的存盤引擎上,并不僅限制于InnoDB,即使在不易遷移的傳統的MyISAM引擎環境,一樣可以使用MHA,

    • 二、MHA簡介:

      MHA(Master High Availability),是比較成熟的MySQL高可用方案,MHA能夠在30秒內實作故障切換,并能在故障切換中,最大可能的保證資料一致性,目前淘寶也正在開發相似產品TMHA,目前已支持一主一從, image

      1、MHA結構

      該軟體由兩部分組成:MHA Manager(管理節點)和MHA Node(資料節點),

      1)MHA Manager

      可以單獨部署在一臺獨立的機器上管理多個master-slave集群,也可以部署在一臺slave節點上,MHA Manager主要運行一些工具,比如masterha_manager工具實作自動監控MySQL Master和實作master故障切換,其它工具實作手動實作master故障切換、在線master轉移、連接檢查等等,

      1.Manager工具包主要工具

      masterha_check_ssh              檢查MHA的SSH配置狀況
      
      masterha_check_repl             檢查MySQL復制狀況
      
      masterha_manger                 啟動MHA
      
      masterha_check_status           檢測當前MHA運行狀態
      
      masterha_master_monitor         檢測master是否宕機
      
      masterha_master_switch          控制故障轉移(自動或者手動)
      
      masterha_conf_host              添加或洗掉配置的server資訊
      

      2)MHA Node

      MHA Node 運行在每臺MySQL服務器上MHA Manager會定時探測集群中的master節點,當master出現故障時,它可以自動將最新資料的slave提升為新的master,然后將所有其他的slave重新指向新的master,整個故障轉移程序對應用程式完全透明,

      部署在所有運行MySQL的服務器上,無論是master還是slave,主要作用有三個,

      Ⅰ、保存二進制日志 如果能夠訪問故障master,會拷貝master的二進制日志

      II、應用差異中繼日志 從擁有最新資料的slave上生成差異中繼日志,然后應用差異日志,

      III、清除中繼日志 在不停止SQL執行緒的情況下洗掉中繼日志

      1.Node工具包

      這些工具通常由MHA Manager的腳本觸發,無需人為操作主要包括以下幾個工具:

      save_binary_logs                保存和復制master的二進制日志
      
      apply_diff_relay_logs           識別差異的中繼日志事件并將其差異的事件應用于其他的slave
      
      filter_mysqlbinlog              去除不必要的ROLLBACK事件(MHA已不再使用這個工具)
      
      purge_relay_logs                清除中繼日志(不會阻塞SQL執行緒)
      

      3)注意

      為了盡可能的減少主庫硬體損壞宕機造成的資料丟失,因此在配置MHA的同時建議配置成MySQL 5.5的半同步復制,關于半同步復制原理各位自己進行查閱,(不是必須)

      2、MAH作業原理

      1.從宕機崩潰的Master保存二進制日志事件(binlog event);

      2.識別含有最新更新的Slave;

      3.應用差異的中繼日志(relay log)到其他Slave;

      4.應用從Master保存的二進制日志事件;

      5.提升一個Slave為新的Master;

      6.使其他的Slave連接新的Master進行復制;

    • 三、部署MHA

      1、環境準備

      [root@server01 ~]# cat /etc/redhat-release 
      CentOS release 6.8 (Final)
      [root@server01 ~]# uname -r
      2.6.32-642.el6.x86_64
      

      2、安裝epel源

      所有節點

      #備份
      mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup
      
      #下載epel源
      wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repo
      
      #生成快取
      yum makecache
      

      3、環境初始化

      1)修改每臺主機名

      172.16.1.241    master
      172.16.1.242    slave01
      172.16.1.243    slave02
      172.16.1.244    manager
      

      其中master對外提供寫服務,備選master(實際的slave,主機名slave01)提供讀服務,slave也提供相關的讀服務,一旦master宕機,將會把備選master提升為新的master,slave指向新的master,

      2)主機名決議

      #每臺服務器執行修改主機名決議

      echo '''
      172.16.1.241    master
      172.16.1.242    slave01
      172.16.1.243    slave02
      172.16.1.244    manager''' >>/etc/hosts
      

      3)ssh無密碼登錄

      使用key登錄,作業中常用,服務器之間無需密碼驗證的,關于配置使用key登錄,一點需要注意:不能禁止 password 登陸,否則會出現錯誤

      注意:所以全部機器都要相互做密鑰登錄,服務器間,無密碼ssh登錄 #主機:master執行命令

      [root@master ~]# ssh-keygen -t rsa
      [root@master ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@manager
      [root@master ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave01
      [root@master ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave02
      

      #主機:slave01執行命令

      [root@slave01 ~]# ssh-keygen -t rsa
      [root@slave01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@manager
      [root@slave01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@master
      [root@slave01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave02
      

      #主機: slave02執行命令

      [root@slave02 ~]# ssh-keygen -t rsa
      [root@slave02 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@manager
      [root@slave02 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@master
      [root@slave02 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave01
      

      #主機:manager執行命令

      [root@manager ~]# ssh-keygen -t rsa
      [root@manager ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@master
      [root@manager ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave01
      [root@manager ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave02
    • 四、規劃mysql

      1)安裝mysql

      #master組態檔/etc/my.cnf 核心配置如下:

      basedir = /application/mysql
      datadir = /application/mysql/data
      port = 3306
      server_id = 241
      socket = /tmp/mysql.sock
      log-bin=mysql-bin
      log-slave-updates
      expire_logs_days = 10
      

      #slave01組態檔/etc/my.cnf 核心配置如下:

      basedir = /application/mysql
      datadir = /application/mysql/data
      port = 3306
      server_id = 242
      socket = /tmp/mysql.sock
      log-bin=mysql-bin
      log-slave-updates
      expire_logs_days = 10
      

      #slave02組態檔/etc/my.cnf 核心配置如下:

      basedir = /application/mysql
      datadir = /application/mysql/data
      port = 3306
      server_id = 243
      socket = /tmp/mysql.sock
      log-bin=mysql-bin
      log-slave-updates
      expire_logs_days = 10
      read_only = 1
      

      2)配置master、slave01和slave02之間的主從復制

      注意:binlog-do-db 和 replicate-ignore-db 設定必須相同, MHA 在啟動時候會檢測過濾規則,如果過濾規則不同,MHA 不啟動監控和故障轉移,

      在MySQL5.6 的Replication配置中,master端同樣要開啟兩個重要的選項,server-id和log-bin,并且選項server-id在全域架構中并且唯一,不能被其它主機使用,這里采用主機ip地址的最后一位充當server-id的值;slave端要開啟relay-log;

      #主機: master執行命令

      [root@master ~]# egrep "log-bin|server_id" /etc/my.cnf 
      server_id = 241
      log-bin=mysql-bin
      

      #主機: slave01執行命令

      [root@slave01 ~]# egrep "log-bin|server_id" /etc/my.cnf 
      server_id = 242
      log-bin=mysql-bin
      

      #主機: slave02執行命令

      [root@slave02 ~]# egrep "log-bin|server_id" /etc/my.cnf 
      server_id = 243
      log-bin=mysql-bin
      

      3)在master、slave01上創建主從同步的賬號,

      slave01是備用master,這個也需要建立授權用戶,

      #master
      [root@master ~]#  mysql  -e "grant replication slave on *.* to 'backup'@'172.16.1.%' identified by 'backup';flush privileges;
      
      #slave01 
      [root@slave01 ~]# mysql  -e "grant replication slave on *.* to 'backup'@'172.16.1.%' identified by 'backup';flush privileges;"
      

      4)在master上執行命令,查看master狀態資訊

      [root@master ~]# mysql -e 'show master status;'
      +------------------+----------+--------------+------------------+
      | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
      +------------------+----------+--------------+------------------+
      | mysql-bin.000007 |      107 |              |                  |
      +------------------+----------+--------------+------------------+
      

      5)在slave01和slave02上執行主從同步

      #slave01配置主從

      [root@slave01 ~]# mysql
      
      mysql> change master to master_host='172.16.1.241',master_user='backup',master_password='backup',master_port=3306,master_log_file='mysql-bin.000007',master_log_pos=107;
      Query OK, 0 rows affected (0.12 sec)
      
      mysql> start slave;
      Query OK, 0 rows affected (0.00 sec)
      
      mysql> show slave status\G
      *************************** 1. row ***************************
                     Slave_IO_State: Waiting for master to send event
                        Master_Host: 172.16.1.241
                        Master_User: backup
                        Master_Port: 3306
                      Connect_Retry: 60
                    Master_Log_File: mysql-bin.000007
                Read_Master_Log_Pos: 107
                     Relay_Log_File: slave01-relay-bin.000002
                      Relay_Log_Pos: 253
              Relay_Master_Log_File: mysql-bin.000007
                   Slave_IO_Running: Yes
                  Slave_SQL_Running: Yes
                    Replicate_Do_DB: 
                Replicate_Ignore_DB: 
                 Replicate_Do_Table: 
             Replicate_Ignore_Table: 
            Replicate_Wild_Do_Table: 
        Replicate_Wild_Ignore_Table: 
                         Last_Errno: 0
                         Last_Error: 
                       Skip_Counter: 0
                Exec_Master_Log_Pos: 107
                    Relay_Log_Space: 411
                    Until_Condition: None
                     Until_Log_File: 
                      Until_Log_Pos: 0
                 Master_SSL_Allowed: No
                 Master_SSL_CA_File: 
                 Master_SSL_CA_Path: 
                    Master_SSL_Cert: 
                  Master_SSL_Cipher: 
                     Master_SSL_Key: 
              Seconds_Behind_Master: 0
      Master_SSL_Verify_Server_Cert: No
                      Last_IO_Errno: 0
                      Last_IO_Error: 
                     Last_SQL_Errno: 0
                     Last_SQL_Error: 
        Replicate_Ignore_Server_Ids: 
                   Master_Server_Id: 241
      1 row in set (0.00 sec)
      
      
      

      #slave02配置主從

      [root@slave02 ~]# mysql
      
      mysql> change master to master_host='172.16.1.241',master_user='backup',master_password='backup',master_port=3306,master_log_file='mysql-bin.000007',master_log_pos=107;
      Query OK, 0 rows affected (0.12 sec)
      
      mysql> start slave;
      Query OK, 0 rows affected (0.00 sec)
      
      mysql> show slave status\G
      *************************** 1. row ***************************
                     Slave_IO_State: Waiting for master to send event
                        Master_Host: 172.16.1.241
                        Master_User: backup
                        Master_Port: 3306
                      Connect_Retry: 60
                    Master_Log_File: mysql-bin.000007
                Read_Master_Log_Pos: 107
                     Relay_Log_File: slave01-relay-bin.000002
                      Relay_Log_Pos: 253
              Relay_Master_Log_File: mysql-bin.000007
                   Slave_IO_Running: Yes
                  Slave_SQL_Running: Yes
                    Replicate_Do_DB: 
                Replicate_Ignore_DB: 
                 Replicate_Do_Table: 
             Replicate_Ignore_Table: 
            Replicate_Wild_Do_Table: 
        Replicate_Wild_Ignore_Table: 
                         Last_Errno: 0
                         Last_Error: 
                       Skip_Counter: 0
                Exec_Master_Log_Pos: 107
                    Relay_Log_Space: 411
                    Until_Condition: None
                     Until_Log_File: 
                      Until_Log_Pos: 0
                 Master_SSL_Allowed: No
                 Master_SSL_CA_File: 
                 Master_SSL_CA_Path: 
                    Master_SSL_Cert: 
                  Master_SSL_Cipher: 
                     Master_SSL_Key: 
              Seconds_Behind_Master: 0
      Master_SSL_Verify_Server_Cert: No
                      Last_IO_Errno: 0
                      Last_IO_Error: 
                     Last_SQL_Errno: 0
                     Last_SQL_Error: 
        Replicate_Ignore_Server_Ids: 
                   Master_Server_Id: 241
      1 row in set (0.00 sec)
      
      
      

      #至此主從已經配置完成!

  • 五、規劃mha

    1)創建mha管理用的復制賬號

    每臺資料庫(master、slave01、slave02)上都要創建賬號,在這里以其中master為例.,

    [root@master ~]# mysql -e "grant all privileges on *.* to 'mha_rep'@'172.16.1.%' identified by '123456';flush privileges;"
    
    [root@master ~]# mysql
    
    mysql> select host,user from mysql.user;
    
    
    

    2)在3臺主機上(master、slave01和slave02)上分別安裝mha4mysql-node包

    安裝完成后會在/usr/local/bin目錄下生成以下腳本檔案:

    -r-xr-xr-x 1 root root 15498 4 2 16:04 apply_diff_relay_logs # 識別差異的中繼日志事件并將其差異的事件應用于其他的slave
    -r-xr-xr-x 1 root root  4807 4 2 16:04 filter_mysqlbinlog   # 去除不必要的ROLLBACK事件(MHA已不再使用這個工具)
    -r-xr-xr-x 1 root root  7401 4 2 16:04 purge_relay_logs # 清除中繼日志(不會阻塞SQL執行緒)
    -r-xr-xr-x 1 root root  7263 4 2 16:04 save_binary_logs   # 保存和復制master的二進制日志
    

    這里以master為例,其它主機同理,

    [root@master ~]# yum install perl-DBD-MySQL -y
    [root@master ~]# rpm -ivh https://downloads.mariadb.com/files/MHA/mha4mysql-node-0.54-0.el6.noarch.rpm
    

    3)在manager上安裝mha4mysql-manager和mha4mysql-node包

    MHA Manager中主要包括了幾個管理員的命令列工具,例如master_manger,master_master_switch等,MHA Manger也依賴于perl模塊,具體如下:

    安裝完成后會在/usr/local/bin目錄下面生成以下腳本檔案

    -r-xr-xr-x 1 root root 15498 4 2 15:59 apply_diff_relay_logs #  識別差異的中繼日志事件并將其差異的事件應用于其他的slave
    -r-xr-xr-x 1 root root  4807 4 2 15:59 filter_mysqlbinlog #  去除不必要的ROLLBACK事件(MHA已不再使用這個工具) 
    -r-xr-xr-x 1 root root  1995 4 2 16:21 masterha_check_repl # 檢查MySQL復制狀況
    -r-xr-xr-x 1 root root  1779 4 2 16:21 masterha_check_ssh #  檢查MHA的SSH配置狀況
    -r-xr-xr-x 1 root root  1865 4 2 16:21 masterha_check_status # 檢測當前MHA運行狀態
    -r-xr-xr-x 1 root root  3201 4 2 16:21 masterha_conf_host # 添加或洗掉配置的server資訊
    -r-xr-xr-x 1 root root  2517 4 2 16:21 masterha_manager # 啟動MHA
    -r-xr-xr-x 1 root root  2165 4 2 16:21 masterha_master_monitor # 檢測master是否宕機
    -r-xr-xr-x 1 root root  2373 4 2 16:21 masterha_master_switch # 控制故障轉移(自動或者手動)
    -r-xr-xr-x 1 root root  3749 4 2 16:21 masterha_secondary_check # 
    -r-xr-xr-x 1 root root  1739 4 2 16:21 masterha_stop # 
    -r-xr-xr-x 1 root root  7401 4 2 15:59 purge_relay_logs # 清除中繼日志(不會阻塞SQL執行緒)
    -r-xr-xr-x 1 root root  7263 4 2 15:59 save_binary_logs # 保存和復制master的二進制日志
    

    復制相關腳本到/usr/local/bin目錄(軟體包解壓縮后就有了,不是必須,因為這些腳本不完整,需要自己修改,這是軟體開發著留給我們自己發揮的,如果開啟下面的任何一個腳本對應的引數,而對應這里的腳本又沒有修改,則會報錯,自己被坑的很慘)

    [root@manager ~]# cd mha4mysql-manager-0.56/samples/scripts/ # 這是我們下載解壓軟體的目錄
    [root@manager scripts]# ll
    總用量 32
    -rwxr-xr-x 1 root root  3443 18 2012 master_ip_failover
     #自動切換時vip管理的腳本,不是必須,如果我們使用keepalived的,我們可以自己撰寫腳本完成對vip的管理,比如監控mysql,如果mysql例外,我們停止keepalived就行,這樣vip就會自動漂移
     
    -rwxr-xr-x 1 root root  9186 18 2012 master_ip_online_change
    #在線切換時vip的管理,不是必須,同樣可以可以自行撰寫簡單的shell完成
    
    -rwxr-xr-x 1 root root 11867 18 2012 power_manager
    #故障發生后關閉主機的腳本,不是必須
    
    -rwxr-xr-x 1 root root  1360 18 2012 send_report
    #因故障切換后發送報警的腳本,不是必須,可自行撰寫簡單的shell完成,
    
    [root@manager ~]# cp * /usr/local/bin/
    
    
    

    #在manager上安裝mha4mysql-manager和mha4mysql-node包

    [root@manager ~]# yum install perl cpan perl-DBD-MySQL perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Net-Telnet -y
    
    [root@manager ~]# rpm -ivh https://downloads.mariadb.com/files/MHA/mha4mysql-node-0.54-0.el6.noarch.rpm
    
    [root@manager ~]# wget https://downloads.mariadb.com/files/MHA/mha4mysql-manager-0.56.tar.gz
    
    [root@manager ~]# tar zvxf mha4mysql-manager-0.56.tar.gz 
    
    [root@manager ~]# cd mha4mysql-manager-0.56
    
    [root@manager ~]# perl Makefile.PL 
    
    [root@manager mha4mysql-manager-0.56]# make && make install
    
    [root@manager mha4mysql-manager-0.56]# mkdir -p /usr/local/mha/scripts
    
    [root@manager mha4mysql-manager-0.56]# cp samples/conf/app1.cnf /usr/local/mha/mha.cnf
    
    [root@manager mha4mysql-manager-0.56]# cp samples/scripts/* /usr/local/mha/scripts/
    

    4)修改manager端mha的組態檔

    記得去注釋

    [root@manager mha4mysql-manager-0.56]# vim /usr/local/mha/mha.cnf
    
    
    [server default]
    user=mha_rep                                    #MHA管理mysql的用戶名
    password=123456                                 #MHA管理mysql的密碼
    manager_workdir=/usr/local/mha                  #MHA的作業目錄
    manager_log=/usr/local/mha/manager.log          #MHA的日志路徑
    ssh_user=root                                   #免秘鑰登陸的用戶名
    repl_user=backup                                #主從復制賬號,用來在主從之間同步資料
    repl_password=backup
    ping_interval=1                                 #ping間隔時間,用來檢查master是否正常
      
    [server1]
    hostname=172.16.1.241
    master_binlog_dir=/application/mysql/data/
    candidate_master=1                              #master宕機后,優先啟用這臺作為master
      
    [server2]
    hostname=172.16.1.242
    master_binlog_dir=/application/mysql/data/
    candidate_master=1
      
    [server3]
    hostname=172.16.1.243
    master_binlog_dir=/application/mysql/data/
    no_master=1                    
    

    5)檢查ssh是否暢通

    注意:所有主機之間必須做SSH免密鑰登錄,否則報錯,研究了兩天,(通過查看MHA的功能實作程序發現)

    [root@manager ~]# masterha_check_ssh --conf=/usr/local/mha/mha.cnf 
    Mon Apr  3 21:42:33 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
    Mon Apr  3 21:42:33 2017 - [info] Reading application default configurations from /usr/local/mha/mha.cnf..
    Mon Apr  3 21:42:33 2017 - [info] Reading server configurations from /usr/local/mha/mha.cnf..
    Mon Apr  3 21:42:33 2017 - [info] Starting SSH connection tests..
    Mon Apr  3 21:42:33 2017 - [debug] 
    Mon Apr  3 21:42:33 2017 - [debug]  Connecting via SSH from [email protected](172.16.1.241:22) to [email protected](172.16.1.242:22)..
    Mon Apr  3 21:42:33 2017 - [debug]   ok.
    Mon Apr  3 21:42:33 2017 - [debug]  Connecting via SSH from [email protected](172.16.1.241:22) to [email protected](172.16.1.243:22)..
    Mon Apr  3 21:42:33 2017 - [debug]   ok.
    Mon Apr  3 21:42:34 2017 - [debug] 
    Mon Apr  3 21:42:34 2017 - [debug]  Connecting via SSH from [email protected](172.16.1.243:22) to [email protected](172.16.1.241:22)..
    Mon Apr  3 21:42:34 2017 - [debug]   ok.
    Mon Apr  3 21:42:34 2017 - [debug]  Connecting via SSH from [email protected](172.16.1.243:22) to [email protected](172.16.1.242:22)..
    Mon Apr  3 21:42:34 2017 - [debug]   ok.
    Mon Apr  3 21:42:34 2017 - [debug] 
    Mon Apr  3 21:42:33 2017 - [debug]  Connecting via SSH from [email protected](172.16.1.242:22) to [email protected](172.16.1.241:22)..
    Mon Apr  3 21:42:33 2017 - [debug]   ok.
    Mon Apr  3 21:42:33 2017 - [debug]  Connecting via SSH from [email protected](172.16.1.242:22) to [email protected](172.16.1.243:22)..
    Mon Apr  3 21:42:34 2017 - [debug]   ok.
    Mon Apr  3 21:42:34 2017 - [info] All SSH connection tests passed successfully.
    

    #如果得到以上結果,表明主機之間ssh互信是暢通的

    6)masterha_check_repl工具檢查mysql主從復制是否成功

    注意:slave01 slave02和master確保已經做好主從復制,否則出錯,(研究22個小時)不懂perl 挺麻煩的,

    [root@manager ~]#  masterha_check_repl --conf=/usr/local/mha/mha.cnf 
    Mon Apr  3 21:44:13 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
    Mon Apr  3 21:44:13 2017 - [info] Reading application default configurations from /usr/local/mha/mha.cnf..
    Mon Apr  3 21:44:13 2017 - [info] Reading server configurations from /usr/local/mha/mha.cnf..
    Mon Apr  3 21:44:13 2017 - [info] MHA::MasterMonitor version 0.56.
    Mon Apr  3 21:44:14 2017 - [info] Dead Servers:
    Mon Apr  3 21:44:14 2017 - [info] Alive Servers:
    Mon Apr  3 21:44:14 2017 - [info]   172.16.1.241(172.16.1.241:3306)
    Mon Apr  3 21:44:14 2017 - [info]   172.16.1.242(172.16.1.242:3306)
    Mon Apr  3 21:44:14 2017 - [info]   172.16.1.243(172.16.1.243:3306)
    Mon Apr  3 21:44:14 2017 - [info] Alive Slaves:
    Mon Apr  3 21:44:14 2017 - [info]   172.16.1.242(172.16.1.242:3306)  Version=5.5.32-log (oldest major version between slaves) log-bin:enabled
    Mon Apr  3 21:44:14 2017 - [info]     Replicating from 172.16.1.241(172.16.1.241:3306)
    Mon Apr  3 21:44:14 2017 - [info]     Primary candidate for the new Master (candidate_master is set)
    Mon Apr  3 21:44:14 2017 - [info]   172.16.1.243(172.16.1.243:3306)  Version=5.5.32-log (oldest major version between slaves) log-bin:enabled
    Mon Apr  3 21:44:14 2017 - [info]     Replicating from 172.16.1.241(172.16.1.241:3306)
    Mon Apr  3 21:44:14 2017 - [info]     Not candidate for the new Master (no_master is set)
    Mon Apr  3 21:44:14 2017 - [info] Current Alive Master: 172.16.1.241(172.16.1.241:3306)
    Mon Apr  3 21:44:14 2017 - [info] Checking slave configurations..
    Mon Apr  3 21:44:14 2017 - [info]  read_only=1 is not set on slave 172.16.1.242(172.16.1.242:3306).
    Mon Apr  3 21:44:14 2017 - [warning]  relay_log_purge=0 is not set on slave 172.16.1.242(172.16.1.242:3306).
    Mon Apr  3 21:44:14 2017 - [warning]  relay_log_purge=0 is not set on slave 172.16.1.243(172.16.1.243:3306).
    Mon Apr  3 21:44:14 2017 - [info] Checking replication filtering settings..
    Mon Apr  3 21:44:14 2017 - [info]  binlog_do_db= , binlog_ignore_db= 
    Mon Apr  3 21:44:14 2017 - [info]  Replication filtering check ok.
    Mon Apr  3 21:44:14 2017 - [info] Starting SSH connection tests..
    Mon Apr  3 21:44:16 2017 - [info] All SSH connection tests passed successfully.
    Mon Apr  3 21:44:16 2017 - [info] Checking MHA Node version..
    Mon Apr  3 21:44:16 2017 - [info]  Version check ok.
    Mon Apr  3 21:44:16 2017 - [info] Checking SSH publickey authentication settings on the current master..
    Mon Apr  3 21:44:16 2017 - [info] HealthCheck: SSH to 172.16.1.241 is reachable.
    Mon Apr  3 21:44:17 2017 - [info] Master MHA Node version is 0.54.
    Mon Apr  3 21:44:17 2017 - [info] Checking recovery script configurations on the current master..
    Mon Apr  3 21:44:17 2017 - [info]   Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/application/mysql/data/ --output_file=/var/tmp/save_binary_logs_test --manager_version=0.56 --start_file=mysql-bin.000007 
    Mon Apr  3 21:44:17 2017 - [info]   Connecting to [email protected](172.16.1.241).. 
      Creating /var/tmp if not exists..    ok.
      Checking output directory is accessible or not..
       ok.
      Binlog found at /application/mysql/data/, up to mysql-bin.000007
    Mon Apr  3 21:44:17 2017 - [info] Master setting check done.
    Mon Apr  3 21:44:17 2017 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
    Mon Apr  3 21:44:17 2017 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user='mha_rep' --slave_host=172.16.1.242 --slave_ip=172.16.1.242 --slave_port=3306 --workdir=/var/tmp --target_version=5.5.32-log --manager_version=0.56 --relay_log_info=/application/mysql/data/relay-log.info  --relay_dir=/application/mysql/data/  --slave_pass=xxx
    Mon Apr  3 21:44:17 2017 - [info]   Connecting to [email protected](172.16.1.242:22).. 
      Checking slave recovery environment settings..
        Opening /application/mysql/data/relay-log.info ... ok.
        Relay log found at /application/mysql/data, up to slave01-relay-bin.000002
        Temporary relay log file is /application/mysql/data/slave01-relay-bin.000002
        Testing mysql connection and privileges.. done.
        Testing mysqlbinlog output.. done.
        Cleaning up test file(s).. done.
    Mon Apr  3 21:44:17 2017 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user='mha_rep' --slave_host=172.16.1.243 --slave_ip=172.16.1.243 --slave_port=3306 --workdir=/var/tmp --target_version=5.5.32-log --manager_version=0.56 --relay_log_info=/application/mysql/data/relay-log.info  --relay_dir=/application/mysql/data/  --slave_pass=xxx
    Mon Apr  3 21:44:17 2017 - [info]   Connecting to [email protected](172.16.1.243:22).. 
      Checking slave recovery environment settings..
        Opening /application/mysql/data/relay-log.info ... ok.
        Relay log found at /application/mysql/data, up to slave02-relay-bin.000002
        Temporary relay log file is /application/mysql/data/slave02-relay-bin.000002
        Testing mysql connection and privileges.. done.
        Testing mysqlbinlog output.. done.
        Cleaning up test file(s).. done.
    Mon Apr  3 21:44:18 2017 - [info] Slaves settings check done.
    Mon Apr  3 21:44:18 2017 - [info] 
    172.16.1.241 (current master)
     +--172.16.1.242
     +--172.16.1.243
    
    Mon Apr  3 21:44:18 2017 - [info] Checking replication health on 172.16.1.242..
    Mon Apr  3 21:44:18 2017 - [info]  ok.
    Mon Apr  3 21:44:18 2017 - [info] Checking replication health on 172.16.1.243..
    Mon Apr  3 21:44:18 2017 - [info]  ok.
    Mon Apr  3 21:44:18 2017 - [warning] master_ip_failover_script is not defined.
    Mon Apr  3 21:44:18 2017 - [warning] shutdown_script is not defined.
    Mon Apr  3 21:44:18 2017 - [info] Got exit code 0 (Not master dead).
    
    MySQL Replication Health is OK.
  • 六、mha實驗模擬

    1)在每次做mha實驗的時候,我們都最好先執行如下命令做檢測

    [root@manager ~]# masterha_check_ssh --conf=/usr/local/mha/mha.cnf
    [root@manager ~]# masterha_check_repl --conf=/usr/local/mha/mha.cnf
    

    #確定兩條命令的回傳結果都是無例外的,然后啟動mha服務

    2)在manager端啟動mha服務并時刻監控日志檔案的輸出變化

    [root@manager ~]# nohup masterha_manager --conf=/usr/local/mha/mha.cnf > /tmp/mha_manager.log 2>&1 &
    [root@manager ~]# ps -ef |grep masterha |grep -v 'grep'
    root      2840  2470  2 10:53 pts/0    00:00:00 perl /usr/local/bin/masterha_manager --conf=/usr/local/mha/mha.cnf
    
    

    3)測驗master宕機后會自動切換

    #測驗前查看slave01,slave02的主從同步情況

    #slave01

    [root@slave01 ~]# mysql -e 'show slave status\G' |egrep 'Slave_IO_Running:|Slave_SQL_Running:'
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
    
    

    #slave02

    [root@slave02 ~]# mysql -e 'show slave status\G' |egrep 'Slave_IO_Running:|Slave_SQL_Running:'
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
    

    #停止master的mysql服務

    [root@master ~]# service mysqld stop
    Shutting down MySQL (Percona Server)..... SUCCESS! 
    

    #manager上查看manager節點日志

    [root@manager ~]# cat /usr/local/mha/manager.log
    
    ----- Failover Report -----
    
    mha: MySQL Master failover 172.16.1.241 to 172.16.1.242 succeeded
    
    Master 172.16.1.241 is down!
    
    Check MHA Manager logs at manager:/usr/local/mha/manager.log for details.
    
    Started automated(non-interactive) failover.
    The latest slave 172.16.1.242(172.16.1.242:3306) has all relay logs for recovery.
    Selected 172.16.1.242 as a new master.
    172.16.1.242: OK: Applying all logs succeeded.
    172.16.1.243: This host has the latest relay log events.
    Generating relay diff files from the latest slave succeeded.
    172.16.1.243: OK: Applying all logs succeeded. Slave started, replicating from 172.16.1.242.
    172.16.1.242: Resetting slave info succeeded.
    Master failover to 172.16.1.242(172.16.1.242:3306) completed successfully.
    

    從上面的輸出可以看出整個MHA的切換程序,共包括以下的步驟:

    1. 組態檔檢查階段,這個階段會檢查整個集群組態檔配置,
    2. 宕機的master處理,這個階段包括虛擬ip摘除操作,主機關機操作(待研究),
    3. 復制dead maste和最新slave相差的relay log,并保存到MHA Manger具體的目錄下,
    4. 識別含有最新更新的slave,
    5. 應用從binlog服務器保存的二進制日志事件(binlog events),
    6. 提升一個slave為新的master進行復制,
    7. 使其他的slave連接新的master進行復制,

    6)驗證new master(172.16.1.242)

    #我們查看slave02的主從同步資訊

    [root@slave02 ~]#  mysql  -e 'show slave status\G' |egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running:'
                      Master_Host: 172.16.1.242     # 表示已經轉移新的ip
                 Slave_IO_Running: Yes  # 表示主從OK
                Slave_SQL_Running: Yes
    

    4)恢復master服務

    #manage洗掉故障轉移檔案

    [root@manager ~]# cat /usr/local/mha/mha.failover.complete 
    [root@manager ~]# rm -rf /usr/local/mha/mha.failover.complete
    

    #master重啟mysql服務

    [root@master ~]# service mysqld start
    Starting MySQL... SUCCESS! 
    

    #在manager的日志檔案中找到主從同步的sql陳述句

    [root@manager ~]# grep MASTER_HOST /usr/local/mha/manager.log
    Mon Apr  3 21:50:59 2017 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='172.16.1.242', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000016', MASTER_LOG_POS=107, MASTER_USER='backup', MASTER_PASSWORD='xxx';
    

    #在master上啟動主從同步,密碼為backup

    master_log_file和master_log_pos引數需要和上面manager的日志檔案中同步的陳述句引數里的值相同,

    mysql> change master to master_host='172.16.1.242',master_user='backup',master_password='backup',master_port=3306,master_log_file='mysql-bin.000016',master_log_pos=107;
    Query OK, 0 rows affected (1.02 sec)
    
    mysql> start slave;
    Query OK, 0 rows affected (0.00 sec)
    
    
    

    #在master和slave02上執行,檢查主從同步是否都正常,這里以master為例,slave02同理

    [root@master ~]#  mysql  -e 'show slave status\G' |egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running:'
                      Master_Host: 172.16.1.242
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
    

    5)再次啟動MHA的manager服務,并停止slave01

    [root@manager ~]# nohup masterha_manager --conf=/usr/local/mha/mha.cnf > /tmp/mha_manager.log 2>&1 &
    

    #關閉slave01的mysql服務

    [root@slave01 ~]# service mysqld stop
    Shutting down MySQL... SUCCESS
    
    [root@slave01 ~]#tail -f /usr/local/mha/manager.log 
    ----- Failover Report -----
    
    mha: MySQL Master failover 172.16.1.242 to 172.16.1.241 succeeded
    
    Master 172.16.1.242 is down!
    
    Check MHA Manager logs at manager:/usr/local/mha/manager.log for details.
    
    Started automated(non-interactive) failover.
    The latest slave 172.16.1.241(172.16.1.241:3306) has all relay logs for recovery.
    Selected 172.16.1.241 as a new master.
    172.16.1.241: OK: Applying all logs succeeded.
    172.16.1.243: This host has the latest relay log events.
    Generating relay diff files from the latest slave succeeded.
    172.16.1.243: OK: Applying all logs succeeded. Slave started, replicating from 172.16.1.241.
    172.16.1.241: Resetting slave info succeeded.
    Master failover to 172.16.1.241(172.16.1.241:3306) completed successfully.
    

    出現故障的快速恢復步驟

    [root@slave01 ~]# service mysqld stop
    Shutting down MySQL... SUCCESS
    
    [root@manager mha]# tail -f /usr/local/mha/manager.log 
    ----- Failover Report -----
    
    mha: MySQL Master failover 172.16.1.242
    
    Master 172.16.1.242 is down!
    
    Check MHA Manager logs at manager:/usr/local/mha/manager.log for details.
    
    Started automated(non-interactive) failover.
    The latest slave 172.16.1.241(172.16.1.241:3306) has all relay logs for recovery.
    Got Error so couldn't continue failover from here.
    
    #出現無法切換回去,后來經過排查是manager /usr/local/mha/mha.cnf [server1] (比較低級的錯誤,排查很久,不過主要是想跟大家分享出現問題如何恢復到之前的狀態,)
    
    hostname=172.16.1.241
    master_binlog_dir=/application/mysql/data/
    candidate_master=1r   #這里多加了一個r#修改完畢
    hostname=172.16.1.241
    master_binlog_dir=/application/mysql/data/
    candidate_master=1  
    
    實作檔案手動恢復到之前的狀態,
    
    #manager
    [root@manager ~]# rm -rf /usr/local/mha/mha.failover.complete
    [root@manager ~]# rm -rf /usr/local/mha/mha.failover.error 
    [root@manager ~]#  nohup masterha_manager --conf=/usr/local/mha/mha.cnf > /tmp/mha_manager.log 2>&1 &
    
    
    #master
    [root@master ~]# mysql
    mysql> stop slave;
    mysql> reset slave;
    mysql> show master status\G
    *************************** 1. row ***************************
                File: mysql-bin.000013     
            Position: 107
        Binlog_Do_DB: 
    Binlog_Ignore_DB: 
    1 row in set (0.00 sec)
    
    
    #slave01
    [root@slave01 ~]# mysql
    mysql> stop slave;
    mysql> change master to master_host='172.16.1.241',master_user='backup',master_password='backup',master_port=3306,master_log_file='mysql-bin.000013',master_log_pos=107;
    mysql> start slave;
    
    # slave01和slave02恢復之前的狀態,
    [root@slave01 ~]# mysql  -e 'show slave status\G' |egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running:'
                      Master_Host: 172.16.1.241
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
    
    
    [root@slave02 ~]#  mysql  -e 'show slave status\G' |egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running:'
                      Master_Host: 172.16.1.241
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
                
    

    #manager上查看manager節點日志

    [root@manager ~]# cat /usr/local/mha/manager.log
    ----- Failover Report -----
    
    mha: MySQL Master failover 172.16.1.242
    
    Master 172.16.1.242 is down!
    
    Check MHA Manager logs at manager:/usr/local/mha/manager.log for details.
    
    Started automated(non-interactive) failover.
    The latest slave 172.16.1.241(172.16.1.241:3306) has all relay logs for recovery.
    Got Error so couldn't continue failover from here.
    

    6)恢復slave01服務

    #洗掉故障轉移檔案

    [root@manager ~]# rm -rf /usr/local/mha/mha.failover.complete
    

    #重啟mysql服務

    [root@slave01 ~]# service mysqld start
    Starting MySQL.. SUCCESS! 
    

    #在manager的日子檔案中找到主從同步的sql陳述句

    [root@manager ~]#  grep MASTER_HOST /usr/local/mha/manager.log
    Tue Apr  4 02:47:33 2017 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='172.16.1.241', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000015', MASTER_LOG_POS=107, MASTER_USER='backup', MASTER_PASSWORD='xxx';
    

    #在slave01上啟動主從同步,密碼為backup 記得修改MASTER_PASSWORD='xxx' 為 MASTER_PASSWORD='bakcup'

    [root@slave01 ~]# mysql
    
    mysql> stop slave
    
    mysql> CHANGE MASTER TO MASTER_HOST='172.16.1.241', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000015', MASTER_LOG_POS=107, MASTER_USER='backup', MASTER_PASSWORD='backup';
    Query OK, 0 rows affected (0.39 sec)
    
    mysql> start slave;
    Query OK, 0 rows affected (0.00 sec)
     
    

    #在slave01和slave02上執行,檢查主從同步是否都正常,

    #slave01
    [root@slave01 ~]# mysql  -e 'show slave status\G' |egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running:'
                      Master_Host: 172.16.1.241
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
            
    #slave02            
    [root@slave02 ~]#  mysql  -e 'show slave status\G' |egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running:'
                      Master_Host: 172.16.1.241
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
    

    7)重啟MHA的manager服務

    [root@manager ~]# nohup masterha_manager --conf=/usr/local/mha/mha.cnf > /tmp/mha_manager.log 2>&1 &
    [1] 30389
    

    七、通過vip實作mysql的高可用

    1)修改/usr/local/mha/mha.cnf

    [server default]
    user=mha_rep
    password=123456
    manager_workdir=/usr/local/mha
    manager_log=/usr/local/mha/manager.log
    ssh_user=root
    master_ip_failover_script=/usr/local/mha/scripts/master_ip_failover     #添加管理vip的腳本
    repl_user=backup
    repl_password=backup
    ping_interval=1
    
    [server1]
    hostname=172.16.1.241
    master_binlog_dir=/application/mysql/data/
    candidate_master=1
    port=3306
    
    [server2]
    hostname=172.16.1.242
    master_binlog_dir=/application/mysql/data/
    candidate_master=1
    port=3306
    
    
    [server3]
    hostname=172.16.1.243
    master_binlog_dir=/application/mysql/data/
    port=3306
    no_master=1
    
    
    

    2)修改腳本/usr/local/mha/scripts/master_ip_failover

    #!/usr/bin/env perl
    use strict;
    use warnings FATAL => 'all';
      
    use Getopt::Long;
    
    my (
        $command,          $ssh_user,        $orig_master_host, $orig_master_ip,
        $orig_master_port, $new_master_host, $new_master_ip,    $new_master_port
    );
      
    my $vip = '172.16.1.240';            #vip地址
    my $key = '1';
    my $ssh_start_vip = "/sbin/ifconfig eth1:$key $vip";        #系結在指定的網卡上面
    my $ssh_stop_vip = "/sbin/ifconfig eth1:$key down";     #我的機器有兩塊網卡eth1是172網段的所有我把vip系結在eth1上,我的eth0網段是10.0.0.%,
      
    GetOptions(
        'command=s'          => \$command,
        'ssh_user=s'         => \$ssh_user,
        'orig_master_host=s' => \$orig_master_host,
        'orig_master_ip=s'   => \$orig_master_ip,
        'orig_master_port=i' => \$orig_master_port,
        'new_master_host=s'  => \$new_master_host,
        'new_master_ip=s'    => \$new_master_ip,
        'new_master_port=i'  => \$new_master_port,
    );
      
    exit &main();
      
    sub main {
      
        print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";
      
        if ( $command eq "stop" || $command eq "stopssh" ) {
      
            my $exit_code = 1;
            eval {
                print "Disabling the VIP on old master: $orig_master_host \n";
                &stop_vip();
                $exit_code = 0;
            };
            if ($@) {
                warn "Got Error: $@\n";
                exit $exit_code;
            }
            exit $exit_code;
        }
        elsif ( $command eq "start" ) {
      
            my $exit_code = 10;
            eval {
                print "Enabling the VIP - $vip on the new master - $new_master_host \n";
                &start_vip();
                $exit_code = 0;
            };
            if ($@) {
                warn $@;
                exit $exit_code;
            }
            exit $exit_code;
        }
        elsif ( $command eq "status" ) {
            print "Checking the Status of the script.. OK \n";
            exit 0;
        }
        else {
            &usage();
            exit 1;
        }
    }
    sub start_vip() {
        `ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
    }
    # A simple system call that disable the VIP on the old_master
     sub stop_vip() {
         `ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
    }
          
    sub usage {
           print
           "Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
    }
    

    3)模擬故障進行切換

    #停止master的mysql服務

    [root@master ~]# service mysqld stop
    Shutting down MySQL... SUCCESS! 
    

    #查看slave02的同步資訊

    [root@slave02 ~]#  mysql  -e 'show slave status\G' |egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running:'
                      Master_Host: 172.16.1.242
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
    
    

    #查看slave01的IP資訊

    [root@slave01 ~]# ifconfig
    eth0      Link encap:Ethernet  HWaddr 00:1C:42:58:08:EF  
              inet addr:10.0.0.242  Bcast:10.0.0.255  Mask:255.255.255.0
              inet6 addr: fe80::21c:42ff:fe58:8ef/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:6925 errors:0 dropped:0 overruns:0 frame:0
              TX packets:2869 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:679548 (663.6 KiB)  TX bytes:420365 (410.5 KiB)
    
    eth0:1    Link encap:Ethernet  HWaddr 00:1C:42:58:08:EF  
              inet addr:172.16.1.240  Bcast:172.16.255.255  Mask:255.255.0.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    
    eth1      Link encap:Ethernet  HWaddr 00:1C:42:F4:DF:3E  
              inet addr:172.16.1.242  Bcast:172.16.1.255  Mask:255.255.255.0
              inet6 addr: fe80::21c:42ff:fef4:df3e/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:10272 errors:0 dropped:0 overruns:0 frame:0
              TX packets:7875 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:1575148 (1.5 MiB)  TX bytes:1644494 (1.5 MiB)
    
    eth1:1    Link encap:Ethernet  HWaddr 00:1C:42:F4:DF:3E  
              inet addr:172.16.1.240  Bcast:172.16.255.255  Mask:255.255.0.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    # 這可以看到我們添加的VIP已經自動添加了
    lo        Link encap:Local Loopback  
              inet addr:127.0.0.1  Mask:255.0.0.0
              inet6 addr: ::1/128 Scope:Host
              UP LOOPBACK RUNNING  MTU:65536  Metric:1
              RX packets:640 errors:0 dropped:0 overruns:0 frame:0
              TX packets:640 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0 
              RX bytes:51251 (50.0 KiB)  TX bytes:51251 (50.0 KiB)
    

    4、恢復master的mysql服務同開始恢復方法一樣,

  • 八、MHA日常維護命令

    1、查看ssh登陸是否成功

    masterha_check_ssh --conf=/usr/local/mha/mha.cnf
    

    2、查看復制是否建立好

    masterha_check_repl --conf=/usr/local/mha/mha.cnf
    

    3、啟動mha

    nohup masterha_manager --conf=/usr/local/mha/mha.cnf > /tmp/mha_manager.log 2>&1 &
    

    4、檢查啟動的狀態

    masterha_check_status --conf=/usr/local/mha/mha.cnf
    

    5、停止mha

    masterha_stop masterha_check_status --conf=/usr/local/mha/mha.cnf
    

    6、failover后下次重啟

    #每次failover切換后會在管理目錄生成檔案app1.failover.complete ,下次在切換的時候會發現有這個檔案導致切換不成功,需要手動清理掉,

    rm -rf /usr/local/mha/mha.failover.complete
    

    九、FAQ(常見問題解答)

    1、可能報錯1

    [root@server02 mha4mysql-node-0.53]# perl Makefile.PL
    Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: inc /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at inc/Module/Install/Can.pm line 6.
    BEGIN failed--compilation aborted at inc/Module/Install/Can.pm line 6.
    Compilation failed in require at inc/Module/Install.pm line 307.
    Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: inc /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at inc/Module/Install/Makefile.pm line 4.
    BEGIN failed--compilation aborted at inc/Module/Install/Makefile.pm line 4.
    Compilation failed in require at inc/Module/Install.pm line 307.
    Can't locate ExtUtils/MM_Unix.pm in @INC (@INC contains: inc /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at inc/Module/Install/Metadata.pm line 316.
    
    

    解決辦法:

    yum install cpan -y
    yum install perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker -y
    cpan ExtUtils::Install
    
    

    如果不想用cpan安裝,那就使用下面這條命令

    yum install perl-ExtUtils-Embed -y
    

    2、可能報錯2

    [root@server02 mha4mysql-node-0.53]# perl Makefile.PL
    Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: /usr/local/lib64/perl      
    BEGIN failed--compilation aborted at Makefile.PL line 3. 
    
    

    解決辦法:

    yum install perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker
    

    3、可能報錯3

    [root@server01 ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf

    報錯:

    
    Sun Apr  2 18:58:10 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
    Sun Apr  2 18:58:10 2017 - [info] Reading application default configurations from /etc/masterha/app1.cnf..
    Sun Apr  2 18:58:10 2017 - [info] Reading server configurations from /etc/masterha/app1.cnf..
    Sun Apr  2 18:58:10 2017 - [info] Starting SSH connection tests..
    Sun Apr  2 18:58:11 2017 - [error][/usr/local/share/perl5/MHA/SSHCheck.pm, ln63] 
    Sun Apr  2 18:58:10 2017 - [debug]  Connecting via SSH from [email protected](172.16.1.50:22) to [email protected](172.16.1.60:22)..
    Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
    Sun Apr  2 18:58:10 2017 - [error][/usr/local/share/perl5/MHA/SSHCheck.pm, ln107] SSH connection from [email protected](172.16.1.50:22) to [email protected](172.16.1.60:22) failed!
    Sun Apr  2 18:58:11 2017 - [error][/usr/local/share/perl5/MHA/SSHCheck.pm, ln63] 
    Sun Apr  2 18:58:10 2017 - [debug]  Connecting via SSH from [email protected](172.16.1.60:22) to [email protected](172.16.1.50:22)..
    Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
    Sun Apr  2 18:58:10 2017 - [error][/usr/local/share/perl5/MHA/SSHCheck.pm, ln107] SSH connection from [email protected](172.16.1.60:22) to [email protected](172.16.1.50:22) failed!
    Sun Apr  2 18:58:11 2017 - [error][/usr/local/share/perl5/MHA/SSHCheck.pm, ln63] 
    Sun Apr  2 18:58:11 2017 - [debug]  Connecting via SSH from [email protected](172.16.1.70:22) to [email protected](172.16.1.50:22)..
    Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
    Sun Apr  2 18:58:11 2017 - [error][/usr/local/share/perl5/MHA/SSHCheck.pm, ln107] SSH connection from [email protected](172.16.1.70:22) to [email protected](172.16.1.50:22) failed!
    SSH Configuration Check Failed!
     at /usr/local/bin/masterha_check_ssh line 44
    

    原因分析,程式需要從manage管理ssh連接,所以會從mysql-test3 ssh到 mysql-test 再ssh到 mysql-test2,問題出在第二次連接,需要輸入key的密碼,導致測驗失敗,所以全部機器都要相互做密鑰登錄,

    4、可能報錯4

    mysql> change master to master_host='172.16.1.241',master_user='backup',master_password='backup',master_port=3306,master_log_file='mysql-bin.000007',master_log_pos=333;

    報錯:

    ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log

    解決方法

    mysql> reset slave;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> change master to master_host='172.16.1.241',master_user='backup',master_password='backup',master_port=3306,master_log_file='mysql-bin.000007',master_log_pos=333;
    Query OK, 0 rows affected (0.15 sec)
    
    mysql> start slave;
    Query OK, 0 rows affected (0.01 sec)
    
    mysql> show slave status\G
    

    5、可能報錯5

    Can't locate Log/Dispatch.pm in @INC(報錯)耗時22個小時才解決

    [root@manager ~]# masterha_check_ssh --conf=/usr/local/mha/mha.cnf

    Can't locate Log/Dispatch.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/local/share/perl5/MHA/MasterMonitor.pm line 28.
    BEGIN failed--compilation aborted at /usr/local/share/perl5/MHA/MasterMonitor.pm line 28.
    Compilation failed in require at /usr/local/bin/masterha_manager line 26.
    BEGIN failed--compilation aborted at /usr/local/bin/masterha_manager line 26.
    
    $ sudo cpan
    cpan[1]> install CPAN
    cpan[2]> install Module::Build
    cpan[3]> quit
    $ sudo cpan
    cpan[1]> install Log::Dispatch
    cpan[2]> install Log::Dispatch::FileRotate
    cpan[3]> quit
    

    6、小知識

    [root@server02 ~]# mysqldump -uroot -p123456 --master-data=https://www.cnblogs.com/qr-k/p/2 --single-transaction -R --triggers -A --event > /server/backup/all_bak_$(date +%F).sql

    -u 資料庫登錄用戶名
    
    -p 資料庫登錄密碼
    
    --event 由于mysql在全量匯出時不匯出event事件表,故需要在全量匯出時忽略事件表,不加此引數會出現告警,    Warning: Skipping the data of table mysql.event. Specify the --events option explicitly
    
    --master-data=https://www.cnblogs.com/qr-k/p/2代表備份時刻記錄master的Binlog位置和Position(位置點)
    
    --single-transaction意思是獲取一致性快照,-R意思是備份存盤程序和函式
    
    --triggres的意思是備份觸發器
    
    -A代表備份所有的庫
    
    更多資訊請自行mysqldump --help查看,或http://note.youdao.com/noteshare?id=60607599966788d19a4d46d4ccd2ce9d
    
    

    查看復制狀態(可以看見復制成功):

    [root@server03 ~]#  mysql -uroot -p123456 -e 'show slave status\G' | egrep 'Slave_IO|Slave_SQL|Until_Log_Pos'
                   Slave_IO_State: Waiting for master to send event
                 Slave_IO_Running: Yes      # IO執行緒
                Slave_SQL_Running: Yes      # SQL執行緒
                    Until_Log_Pos: 0        # 主從之間的延遲
    

    修改app1.cnf組態檔,修改后的檔案內容如下: 配置引數注釋請看:MHA app1.cnf 組態檔注釋

    (2)設定relay log的清除方式(在每個slave節點上):

    server03
    [root@server03 ~]# mysql -uroot -p123456 -e 'set global relay_log_purge=0'
    
    server04
    [root@server04 ~]# mysql -uroot -p123456 -e 'set global relay_log_purge=0'
    

    注意:

    MHA在發生切換的程序中,從庫的恢復程序中依賴于relay log的相關資訊,所以這里要將relay log的自動清除設定為OFF,采用手動清除relay log的方式,

    在默認情況下,從服務器上的中繼日志會在SQL執行緒執行完畢后被自動洗掉,但是在MHA環境中,這些中繼日志在恢復其他從服務器時可能會被用到,因此需要禁用中繼日志的自動洗掉功能,

    定期清除中繼日志需要考慮到復制延時的問題,在ext3的檔案系統下,洗掉大的檔案需要一定的時間,會導致嚴重的復制延時,為了避免復制延時,需要暫時為中繼日志創建硬鏈接,因為在linux系統中通過硬鏈接洗掉大檔案速度會很快,(在mysql資料庫中,洗掉大表時,通常也采用建立硬鏈接的方式)

    MHA節點中包含了pure_relay_logs命令工具,它可以為中繼日志創建硬鏈接,執行SET GLOBAL relay_log_purge=1,等待幾秒鐘以便SQL執行緒切換到新的中繼日志,再執行SET GLOBAL relay_log_purge=0,

    pure_relay_logs腳本引數如下所示:

    --user mysql                      用戶名
    --password mysql                  密碼
    --port                            埠號
    --workdir                         指定創建relaylog的硬鏈接的位置,默認是/var/tmp,由于系統不同磁區創建硬鏈接檔案會失敗,故需要執行硬鏈接具體位置,成功執行腳本后,硬鏈接的中繼日志檔案被洗掉
    --disable_relay_log_purge         默認情況下,如果relay_log_purge=1,腳本會什么都不清理,自動退出,通過設定這個引數,

轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/107759.html

標籤:MySQL

上一篇:pb9.0 + sqlserver2000 如何呼叫寫好的存盤程序并且獲取回傳的引數 太奇怪了

下一篇:問個關于PB的串口通信的問題,本人現用PB9.0

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀:**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題,由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視,實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶,一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀:**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高,采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐,遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀:**滴滴資料通道引擎承載著全公司的資料同步,為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加,資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程,遇到的問題以及今后的規劃。 #1. 背景 資料,對于任何一家互聯網公司來說都是非常重要的資產,公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀:**深耕人工智能領域,致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎,這次獲獎的專案是什么呢?一起來看看詳細報道吧! 近日,由國際計算語言學協會ACL(The Association for Computational Linguistics)舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp? MPP (Massively Parallel Processing),即大規模并行處理,在資料庫非共享集群中,每個節點都有獨立的磁盤存盤系統和記憶體系統,業務資料根據資料庫模型和應用特點劃分到各個節點上,每臺資料節點通過專用網路或者商業通用網路互相連接,彼此協同計算,作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀:**指標體系是什么?如何使用OSM模型和AARRR模型搭建指標體系?如何統一流程、規范化、工具化管理指標體系?本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標,系統化的組織起來,通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索,LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料,可以使用下面的 SQL 陳述句: SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀:**Ceph是國際知名的開源分布式存盤系統,在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統, ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章,這一次主要寫一個嵌套的聚合,例如先對sex集合,再對desc聚合,最后再對age求和,共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by,avg,sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack(ELK)部署

    傻瓜式部署,只需替換IP與用戶 導讀: 現ELK四大組件分別為:Elasticsearch(核心)、logstash(處理)、filebeat(采集)、kibana(可視化) 下載均在https://www.elastic.co/cn/downloads/下tar包,各組件版本最好一致,配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取? 快取就是資料交換的緩沖區(稱作Cache),是存盤資料的臨時地方,一般讀寫性能較高。 快取的作用: 降低后端負載 提高讀寫效率,降低回應時間 快取的成本: 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下,當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:33:24 more
  • MySQL中binlog備份腳本分享

    關于MySQL的二進制日志(binlog),我們都知道二進制日志(binlog)非常重要,尤其當你需要point to point災難恢復的時侯,所以我們要對其進行備份。關于二進制日志(binlog)的備份,可以基于flush logs方式先切換binlog,然后拷貝&壓縮到到遠程服務器或本地服務器 ......

    uj5u.com 2023-04-20 08:28:06 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼: 發送驗證碼的介面為:http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式:PO ......

    uj5u.com 2023-04-20 08:27:27 more
  • 快取與資料庫雙寫一致性幾種策略分析

    本文將對幾種快取與資料庫保證資料一致性的使用方式進行分析。為保證高并發性能,以下分析場景不考慮執行的原子性及加鎖等強一致性要求的場景,僅追求最終一致性。 ......

    uj5u.com 2023-04-20 08:26:48 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼,對其進行一對一優化,而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題,盡量不要讓一個事務拖太長的時間 例如檔案上傳時,應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:26:35 more
  • 云時代,MySQL到ClickHouse資料同步產品對比推薦

    ClickHouse 在執行分析查詢時的速度優勢很好的彌補了MySQL的不足,但是對于很多開發者和DBA來說,如何將MySQL穩定、高效、簡單的同步到 ClickHouse 卻很困難。本文對比了 NineData、MaterializeMySQL(ClickHouse自帶)、Bifrost 三款產品... ......

    uj5u.com 2023-04-20 08:26:29 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼,對其進行一對一優化,而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題,盡量不要讓一個事務拖太長的時間 例如檔案上傳時,應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:25:13 more
  • Redis 報”OutOfDirectMemoryError“(堆外記憶體溢位)

    Redis 報錯“OutOfDirectMemoryError(堆外記憶體溢位) ”問題如下: 一、報錯資訊: 使用 Redis 的業務介面 ,產生 OutOfDirectMemoryError(堆外記憶體溢位),如圖: 格式化后的報錯資訊: { "timestamp": "2023-04-17 22: ......

    uj5u.com 2023-04-20 08:24:54 more
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取? 快取就是資料交換的緩沖區(稱作Cache),是存盤資料的臨時地方,一般讀寫性能較高。 快取的作用: 降低后端負載 提高讀寫效率,降低回應時間 快取的成本: 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下,當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:24:03 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼: 發送驗證碼的介面為:http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式:PO ......

    uj5u.com 2023-04-20 08:23:11 more