業務不中斷，PXC叢集單機多例項拆分消除資料庫隱患

資料庫 · 發表 2018-09-25 10:47:44

摘要：作者介紹劉書浩，中國移動DBA，負責“移動雲”業務系統的資料庫運維、標準化等工作；擅長MySQL 技術領域，熟悉MySQL複製結構、Cluster 架構及運維優化；具有自動化運維經驗，負責“移動雲”資料庫管理平臺的開發和部署。過去兩年，我主要從事“移動雲”資料庫的運維...

作者介紹

劉書浩，中國移動DBA，負責“移動雲”業務系統的資料庫運維、標準化等工作；擅長SQL/">MySQL 技術領域，熟悉MySQL複製結構、Cluster 架構及運維優化；具有自動化運維經驗，負責“移動雲”資料庫管理平臺的開發和部署。

過去兩年，我主要從事“移動雲”資料庫的運維工作，有幸見證了“移動雲”的快速發展，每當接維一個新的資源池，通常需要先進行標準化方面的工程改造，目的是以統一的標準體系開展後續的維護工作。通過大大小小的工程變更，積累了一些實踐經驗，下面我跟大家分享一個PXC叢集單機多例項拆分的工程案例。

一、案例背景

1、問題簡述

通常情況下，根據業務垂直切分原則，不同業務資料庫需要單獨部署，一個MyQL例項不可存放多個業務庫。但在某些特殊情況下，比如：物理機資源緊張、業務上線壓力大等情況，部署階段工程人員可能會將兩個不同子系統資料庫部署在同一物理機甚至同一例項，以節省資源、加快實施進度。這樣造成的結果是業務耦合性過高，一旦出現問題會殃及池魚，增加了故障定位的難度。

我們生產環境就曾經發生過因CLM系統問題引發資料庫例項鎖，導致移動雲華中節點OP門戶無法載入、客戶無法訂購雲產品的故障。

為消除資料庫存在的安全隱患，我們決定採用多例項的方法解決，在帶業務的情況下對兩個子系統（OP和CLM）資料庫例項進行拆分，拆分完成後一個系統將對應一個業務庫，互不干擾。在正式闡述變更方案之前，先簡單介紹下 “移動雲”生產環境使用的MySQL叢集以及業務系統名稱。

2、PXC

PXC，即Percona XtraDB Cluster，Percona的一個MySQL分支版本，是一個可以實時同步的MySQL叢集，基於廣播write set和事務驗證來實現多節點同時commit、衝突事務回滾等功能，具有強資料一致性。

“移動雲”管理域資料庫是在PXC架構基礎上進行封裝，而PXC又是以開源Galera Cluster為基礎，為表述方便，本文用PXC或Galera叢集代替定製化產品名稱。

3、系統名稱

OP： “移動雲”門戶系統，使用者通過登入OP入口網站進行相關雲產品的訂購和使用，具有使用者自服務能力。
CLM：資源池管理平臺，目前用於效能資料採集、監控和告警傳遞。

二、PXC叢集單機多例項拆分

1、改造方案

最初考慮了兩個方案：

方案一是在物理機上開啟兩臺虛擬機器分開部署OP和CLM資料庫，因為需要安裝虛擬機器並重新部署PXC叢集，業務中斷的時間會比較長；
方案二是物理機上拆分不同例項，重新規劃埠號、程式目錄、PID、SOCKET檔案路徑。如果採用“先擴容再主動分裂叢集的方式”基本可以保證線上情況下OP業務不受影響，但CLM系統性能資料會有少部分缺失，該方案中斷業務時間短，正常情況下不超過15分鐘。

從業務影響角度考慮，最終選擇了方案二，下面介紹下例項拆分的實施過程。

2、架構現狀

首先看一下變更實施前“移動雲”華中節點OP、CLM資料庫部署情況，從下圖可以看到兩個子系統資料庫部署在同一例項，業務耦合度高：

“移動雲”生產環境PXC叢集預設配置為多主的方式，每個節點都可以提供讀寫服務，不支援程式內指定實際物理IP，應用程式通過HAproxy負載均衡元件指定VIP連線資料庫，如上圖中openstack和activemq為OP相關服務，與CLM服務通過不同的虛擬IP和服務埠號進行區分，結合上層HAproxy+Keepalived可以實現叢集的高可用。資料庫對外服務埠為3306，叢集成員之間的通訊埠為4567，叢集節點SST和IST專用埠分別為4444和4568 ，各節點使用TCP/IP協議通訊。

3、拆分原則

垂直切分，按業務分類進行拆分，OP系統後端資料庫保留在原例項中，CLM系統資料庫遷移到新例項中；
方案採用“先擴容再主動分裂叢集的方式”，改造過程中儘量保證OP業務不受影響。

4、埠設計

通過修改資料庫配置檔案，保留OP例項原來的埠設計，拆分出來的CLM例項採用新的內外埠，以此來區分同一物理機上兩個不同的資料庫例項，具體如下：

資料庫對外服務的埠： OP例項的埠是3306，CLM例項的埠是3307；
叢集組成員的溝通埠： OP例項的埠是4567，CLM例項的埠是4667；
SST專用埠： OP例項的埠是4444，CLM例項的埠是4445；
IST專用埠： OP例項A的埠是4568，CLM例項的埠是4668。

另外，還需要修改HAproxy配置檔案中CLM資料庫的訪問埠，將CLM資料庫例項的對外服務埠修改為3307：

5、目錄拆分

OP例項沿用原有標準化目錄，CLM例項相關的資料目錄、日誌目錄、程式目錄、軟連線、pid、socket檔案路徑要重新指定，如下表所示：

6、配置檔案

保留OP例項原my.cnf配置檔案，為CLM例項建立新的配置檔案my_clm.cnf，在配置檔案中對mysql內外埠、資料目錄、日誌目錄、pid、socket檔案路徑等引數進行重新配置，如下表所示：

要注意的是啟動方式有所變化，因為需要維護兩個配置檔案，所以OP和CLM不能都採用原方式啟動，啟動CLM cluster的時候，需要指定新的配置檔案，例如：

初始化叢集首節點：

mysql_safe --defaults-file = /apps/conf/bcrdb/my_clm.cnf --wsrep-new-cluster &
叢集次節點：

mysql_safe --defaults-file = /apps/conf/bcrdb/my_clm.cnf &
叢集次節點：

mysql_safe --defaults-file = /apps/conf/bcrdb/my_clm.cnf &

7、拆分步驟

Step 1：登入RW3節點，為拆分出來的CLM資料庫例項建立目錄、軟連線，並編寫配置檔案my_clm.cnf ，重新規劃內、外埠以及PID、SOCKET檔案路徑，完成後關閉RW3節點資料庫程序，如下圖所示：

Step 2：同步資料，啟動新的CLM資料庫例項與原叢集RW1、RW2節點進行資料同步（SST），這裡需要注意的是，啟動CLM例項時需指定原配置檔案 mysql_safe --defaults-file = /apps/conf/bcrdb/my.cnf，從而保證拆分出來的CLM例項可以加入原有叢集進行資料同步。

Step 3：恢復OP資料庫叢集狀態，CLM例項完成資料同步後，使用命令：mysqladmin --defaults-file = /apps/conf/bcrdb/my.cnf -uroot -p shutdown關閉CLM例項程序，啟動OP資料庫RW3節點，恢復OP資料庫叢集狀態。

Step 4：修改HAproxy配置檔案，使CLM例項以3307埠對外提供服務，從而將CLM例項徹底從原叢集拆分出來，啟動CLM叢集第一個節點RW3時需指定my_clm.cnf配置檔案：

mysql_safe --defaults-file = /apps/conf/bcrdb/my_clm.cnf --wsrep-new-cluster &

Step 5：重複步驟1到4，完成CLM cluster的啟動，注意啟動CLM例項RW1、RW2節點時啟動命令有所不同：mysql_safe --defaults-file = /apps/conf/bcrdb/my_clm.cnf &，並且需要根據叢集節點資訊的不同先調整my_clm.cnf引數配置。

Step 6：修改自動化運維指令碼，由於CLM例項拆分出來後，配置檔名稱、資料目錄有所不同，需要在備份、巡檢和監控指令碼中進行相應調整，比如備份指令碼需進行如下修改：

full_backup()
{
    echo "$(date +%F\ %T)  start full backup..."
    innobackupex --defaults-file=/apps/svr/bcrdb/conf/my_clm.cnf
                           --slave-info
                           --galera-info
                           --user=$bakuser
                           --password=$bakpwd
                           --no-timestamp
                           --kill-long-query-type=select
                           --kill-long-queries-timeout=20
                           --rsync --history=${bakname} ${bakdir}/${bakname}_full
    [ $? -ne 0 ] && echo "$(date +%F\ %T)  backup failed!" && exit 1
    echo "$(date +%F\ %T)  backup complete!"
}
 
 
incr_backup()
{
 
    lastname=`$mysqlcmd "select name from xtrabackup_history where is_success='Y' and name like 'BCRDB_BC_CLM%' order by end_time desc limit 1"`
    if [ "$lastname" != "NULL" ] && [ -n "$lastname" ] ;then
        echo "$(date +%F\ %T)  start incremental backup since $lastname..."
        innobackupex --defaults-file=/apps/svr/bcrdb/conf/my_clm.cnf
                               --slave-info
                               --galera-info
                               --user=$bakuser
                               --password=$bakpwd
                               --no-timestamp
                               --kill-long-query-type=select
                               --kill-long-queries-timeout=20
                               --rsync --history=${bakname}
                               --incremental --incremental-history-name=$lastname ${bakdir}/${bakname}_incr
        [ $? -ne 0 ] && echo "$(date +%F\ %T)  backup failed!" && exit 1
        echo "$(date +%F\ %T)  backup complete!"
    else
        echo "$(date +%F\ %T)  there is no backup history, cann't start incremental backup, start full backup instead..."
        full_backup
    fi
}

Step 7：建立crontab：

備份執行計劃： 30 2 * * * /apps/sh/backup_clm.sh -d 60 -n bcclm -t auto>/apps/sharedstorage/logs/bcrdb_clm/backuplog/backup_$(date '+\%Y\%m\%d_\%H\%M\%S').log 2>&1
Zabbix監控執行計劃： */1 * * * * /usr/zagt/zabbix_scripts/zbx_mysql_status.sh > /dev/null

8、變更回顧

通過以上步驟就完成了OP和CLM資料庫的例項拆分，實現了PXC叢集單機多例項部署，經測試OP業務未受影響，CLM因資料庫中斷丟失少量效能資料，埠的更改並沒有導致網路問題。

三、結語

工程變更前期方案准備非常重要，特別是帶業務進行操作，要預計到可能發生的問題點，並進行充分的測試，把每個操作細節都確定下來，整理為操作命令集合，並準備好回退方案。

本次變更大概用了一個月的時間進行準備，變更是在晚上10點後業務低谷期進行，各業務負責同事也參與其中，變更期間他們隨時準備處理突發情況，從而保證變更操作的順利完成。

業務不中斷，PXC叢集單機多例項拆分消除資料庫隱患

一、案例背景

二、PXC叢集單機多例項拆分

初始化叢集首節點：

叢集次節點：

叢集次節點：

三、結語

您可能也會喜歡…