docker中mysql備庫恢復主從同步

IT那活兒發布于2023-01-11 13:20 / 3516人閱讀

一. 背景描述

應某項目需求，需要將mysql備庫恢復主從同步，數據庫版本為5.7.24，登錄數據庫檢查環境，主庫運行正常，備庫同步已停止。

查看備庫slave狀態：Slave_IO_Running: No，且同步的日志主庫已不存在，信息如下：

mysql> show slave status G;
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: xxx.xx.xxx.xxx
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: master-bin.030596
          Read_Master_Log_Pos: 154
               Relay_Log_File: slave-relay-bin.018035
                Relay_Log_Pos: 369
        Relay_Master_Log_File: master-bin.030596
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
省略部分輸出……
                Last_IO_Errno: 1595
                Last_IO_Error: Relay log write failure: could not queue event from master
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
                  Master_UUID: b88f562f-14ab-11e9-9191-0242ac110002
             Master_Info_File: /var/lib/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 200616 16:45:39
     Last_SQL_Error_Timestamp: 
省略部分輸出……
1 row in set (0.00 sec)

登錄主庫，查看：當前的binglog日志為：master-bin.069047

mysql> show master status G;
*************************** 1. row ***************************
             File: master-bin.069047
         Position: 98055615
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: b88f562f-14ab-11e9-9191-0242ac110002:1-1131232768
1 row in set (0.00 sec)

主庫binlog日志保留15天，信息如下：

mysql> show variables like expire_logs_days;
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 15    |
+------------------+-------+

主庫當前最早的binlog日志為：5月29日的master-bin.067546

mysql> show variables like log_bin%;
+---------------------------------+---------------------------------+
| Variable_name | Value |
+---------------------------------+---------------------------------+
| log_bin | ON |
| log_bin_basename | /var/lib/mysql/master-bin |
| log_bin_index | /var/lib/mysql/master-bin.index |
| log_bin_trust_function_creators | ON |
| log_bin_use_v1_row_events | OFF |
+---------------------------------+---------------------------------+

mysql@41341d8089d3:/var/lib/mysql$ ls -ltr master-bin.* |more
-rw-r----- 1 mysql mysql 1073742835 May 29 13:38 master-bin.067546
-rw-r----- 1 mysql mysql 1178992991 May 29 13:49 master-bin.067547
-rw-r----- 1 mysql mysql 1073778127 May 29 14:03 master-bin.067548
-rw-r----- 1 mysql mysql 1073982895 May 29 14:05 master-bin.067549
-rw-r----- 1 mysql mysql 1074024190 May 29 14:07 master-bin.067550
-rw-r----- 1 mysql mysql 1480555563 May 29 14:08 master-bin.067551
-rw-r----- 1 mysql mysql 1073811010 May 29 14:13 master-bin.067552
-rw-r----- 1 mysql mysql 1073757290 May 29 14:17 master-bin.067553
-rw-r----- 1 mysql mysql 1073901502 May 29 14:20 master-bin.067554
-rw-r----- 1 mysql mysql 1073801430 May 29 14:23 master-bin.067555

從上面主庫、備庫的查詢信息看，備庫需要的binlog日志，在主庫上已不存在，備庫要恢復主備同步，需要重新初始化數據。

二. 備庫恢復主從同步實施過程

1. 主、備服務器掛在NAS盤

主庫數據量較大，通過innobackupex備份出的數據無法放到本地，將申請的NAS盤同時掛在到主庫服務器與備庫服務，免去備份文件拷貝到備庫過程。

2. 備庫NAS盤中解壓xtrabackup工具

上傳Xtrabackup軟件包至NAS盤中，校驗軟件包的MD5值后，進行解壓操作，如下：

——md5校驗
xxxxxx:/mnt/database-nas/slave_test # md5sum percona-xtrabackup-2.4.23-Linux-x86_64.glibc2.12.tar.gz
990fca4d309cf6854253f9983499ce22 percona-xtrabackup-2.4.23-Linux-x86_64.glibc2.12.tar.gz

——解壓
xxxxxx:/mnt/database-nas/slave_test # tar zxvf percona-xtrabackup-2.4.23-Linux-x86_64.glibc2.12.tar.gz

3. 主、備庫主機測試innobackupex可用

向環境變量PATH中添加innobackup工具的路徑：

——新增變量
XTRABACKUP_HOME=/mnt/database-nas/slave_test/percona-xtrabackup-2.4.23-Linux-x86_64.glibc2.12

——PATH變量修改
PATH=$JAVA_HOME/bin:$PATH:$XTRABACKUP_HOME/bin

—— innobackupex命令測試
innobackupex -v ##可以正常輸出版本號。

4. 主庫備份數據至NAS盤

備庫主庫數據至NAS盤中，建議在業務低峰期進行操作，主庫數據量2.5T，備份程序跑了3個小時，生成備份文件1.6T。

——備份：
innobackupex --defaults-file=/data/mysqlconfig/mysqld.conf --user=root --password=xxxxxx --port=3306 --host=xxx.xxx.xxx.xxx --datadir=/data/mysqldata /mnt/database-nas/mysql_full_backup

——應用redo，使備份出的數據文件處于一致性狀態
innobackupex --defaults-file=/data/mysqlconfig/mysqld.conf --apply-log /mnt/database-nas/mysql_full_backup/2021-07-09_20-24-22/

5. 備庫恢復數據

備庫與主庫掛載了相同的NAS盤，在備庫服務器上可以直接認到掛在的NAS盤。開始在備庫進行數據庫恢復，命令如下：

——查看當前在運行的mysql備庫容器
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e12538fa0c7a registry.paas/cgos/mysql:5.7.24sec "docker-entrypoint..." 2 years ago Up 3 days 0.0.0.0:3306->3306/tcp, 33060/tcp mysql-slave

——關閉備庫容器
# docker stop mysql-slave

——刪除備庫數據目錄下的文件
# cd /data/mysqldata/
# rm -rf *

——執行恢復命令
innobackupex --defaults-file=/data/mysqlconfig/mysqld.conf --datadir=/data/mysqldata --copy-back /mnt/database-nas/mysql_full_backup/2021-07-09_20-24-22

——恢復完后運行備庫容器
docker start mysql-slave

6. 備庫恢復主從關系

——查看binlog位點
xxxxxxx:/mnt/database-nas/mysql_full_backup/2021-07-09_20-24-22 # cat xtrabackup_binlog_pos_innodb
master-bin.071809 578330673

——清除relay log信息
reset slave;

——備庫執行恢復主從同步腳本
CHANGE MASTER TO
MASTER_HOST=xxx.xx.xxx.xxx,
MASTER_USER=replication,
MASTER_PASSWORD=********,
MASTER_PORT=3306,
MASTER_LOG_FILE=master-bin.071809,
MASTER_LOG_POS=578330673,
MASTER_CONNECT_RETRY=10;

——查看備庫slave狀態
show slave stauts G;
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

主備同步已恢復，備庫開始追日志。

三. 實施過程遇到的問題及解決方法

問題1：
innobackupex命令遇到：InnoDB: Error number 24 means Too many open files

具體報錯信息如下：

InnoDB: Operating system error number 24 in a file operation.

InnoDB: Error number 24 means Too many open files

InnoDB: Some operating system error numbers are described at http://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.html

InnoDB: File ./wf_public_layout/pub_application_introduce_t.ibd: open returned OS error 124. Cannot continue operation

InnoDB: Cannot continue operation.

檢查主機參數 ulimit -a

core file size (blocks, -c) 0

data seg size (kbytes, -d) unlimited

scheduling priority (-e) 0

file size (blocks, -f) unlimited

pending signals (-i) 514100

max locked memory (kbytes, -l) 64

max memory size (kbytes, -m) unlimited

open files (-n) 1024

pipe size (512 bytes, -p) 8

POSIX message queues (bytes, -q) 819200

real-time priority (-r) 0

stack size (kbytes, -s) 8192

cpu time (seconds, -t) unlimited

max user processes (-u) 514100

virtual memory (kbytes, -v) unlimited

file locks (-x) unlimited

發現open files參數為1024，參數值為系統默認值。

解決方法：

ulimit -n 16384 ##調大open files值。

注：此方法，參數值臨時生效，此次備庫恢復操作過程中，除必要的設置，其他設置均為臨時設置。

問題2：
主從同步復制用戶密碼錯誤

mysql數據庫中用于主從復制的用戶replication，業務側密碼忘記，經業務側同意后，修改復制用戶密碼，過程如下：

--查看復制用戶權限：
mysql> show grants for replication@%;
+-----------------------------------------------------+
| Grants for replication@%                  |
+-----------------------------------------------------+
| GRANT REPLICATION SLAVE ON *.* TO replication@% |
+-----------------------------------------------------+

--修改復制用戶密碼
GRANT REPLICATION SLAVE ON *.* TO replication@% identified by *********;

END

更多精彩干貨分享

點擊下方名片關注

IT那活兒

云服務器 GPU云服務器 mysql主從同步 mysql主從同步原理監控MySQL主從同步 MySQL主從同步實操

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129817.html

MySQL 復制 - 性能與擴展性的基石 2：部署及其配置

摘要：配置主庫和備庫。主庫當前的二進制日志文件，和獲得數據快照時在該二進制日志文件中的偏移量。它能夠在備份時不阻塞服務器的操作，因此可以在不影響主庫的情況下設置備庫。 showImg(https://segmentfault.com/img/bVbqOEk?w=720&h=480); 正所謂理論造航母，現實小帆船。單有理論，不動手實踐，學到的知識猶如空中樓閣。接下來，我們一起來看下如何一步步...

劉德剛 2019-08-16 16:19 評論0 收藏0
MySQL 復制 - 性能與擴展性的基石 2：部署及其配置

摘要：配置主庫和備庫。主庫當前的二進制日志文件，和獲得數據快照時在該二進制日志文件中的偏移量。它能夠在備份時不阻塞服務器的操作，因此可以在不影響主庫的情況下設置備庫。 showImg(https://segmentfault.com/img/bVbqOEk?w=720&h=480); 正所謂理論造航母，現實小帆船。單有理論，不動手實踐，學到的知識猶如空中樓閣。接下來，我們一起來看下如何一步步...

fobnn 2019-07-01 12:39 評論0 收藏0

發表評論

登陸后可評論

0條評論

IT那活兒

男|高級講師

我要關注我要私信

TA的文章

消息中間件故障分析一例

閱讀 1346·2023-01-11 13:20
RAC雙節點crash回復一例

閱讀 1684·2023-01-11 13:20
ORA-600處理一例

閱讀 1132·2023-01-11 13:20
雙節點RAC實例2 HANG 故障分析一例

閱讀 1858·2023-01-11 13:20
RAC集群節點1重啟分析一例

閱讀 4100·2023-01-11 13:20
CRS啟動報錯CRS-1656處理分享

閱讀 2704·2023-01-11 13:20
oracle 12CR2打補丁報錯處理一例

閱讀 1385·2023-01-11 13:20
分布式緩存組件故障分析及監控優化

閱讀 3597·2023-01-11 13:20

国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

docker中mysql備庫恢復主從同步

1. 主、備服務器掛在NAS盤

2. 備庫NAS盤中解壓xtrabackup工具

3. 主、備庫主機測試innobackupex可用

4. 主庫備份數據至NAS盤

5. 備庫恢復數據

6. 備庫恢復主從關系

問題1：
innobackupex命令遇到：InnoDB: Error number 24 means Too many open files

問題2：
主從同步復制用戶密碼錯誤

相關文章

MySQL 復制 - 性能與擴展性的基石 2：部署及其配置

MySQL 復制 - 性能與擴展性的基石 2：部署及其配置

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

消息中間件故障分析一例

RAC雙節點crash回復一例

ORA-600處理一例

雙節點RAC實例2 HANG 故障分析一例

RAC集群節點1重啟分析一例

CRS啟動報錯CRS-1656處理分享

oracle 12CR2打補丁報錯處理一例

分布式緩存組件故障分析及監控優化

最新活動

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

docker中mysql備庫恢復主從同步

1. 主、備服務器掛在NAS盤

2. 備庫NAS盤中解壓xtrabackup工具

3. 主、備庫主機測試innobackupex可用

4. 主庫備份數據至NAS盤

5. 備庫恢復數據

6. 備庫恢復主從關系

問題1：innobackupex命令遇到：InnoDB: Error number 24 means Too many open files

問題2：主從同步復制用戶密碼錯誤

相關文章

發表評論

0條評論

男|高級講師

TA的文章

最新活動

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

問題1：
innobackupex命令遇到：InnoDB: Error number 24 means Too many open files

問題2：
主從同步復制用戶密碼錯誤