redis數據恢復

公司線上一個項目數據存儲采用MySQL，共分為10個庫，分布在4臺機器上，每個庫數據量約為10G，各機器均采用RAID5加速磁盤訪問；
當同時在線人數達高峰期（10w），DB磁盤IO壓力巨大，導致訪問巨慢，，在線人數就很難上不去了。

針對上面描述情況，使用redis后可有效解決這一瓶頸，因為Redis數據讀寫都是直接操作內。

解決方案：
將部分數據壓縮導入到redis后，總數據量約30G（轉換成redis數據類型數據量），一主一從模型，共兩組。
一臺機器內存32G，開10個實例，共20個實例，多實例方便做持久化。

同樣適用于上面的redis持久化策略調整方案（思路和上面一致）

主從庫配置：
主庫：關閉save開展，aof默認不打開，允許從庫訪問。主庫設置了密碼訪問requirepass My#redis
從庫：需增加配置：開啟AOF持久化，關閉save快照，設置密碼；
從庫10個實例的配置文件分別為：slave6001.conf ~ slave6010.conf
slave6001.conf配置內容如下（其他實例拷貝這個，修改端口等其他信息即可）

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

daemonize?yes

pidfile?/var/run/slave6001.pid

port 6001

timeout 300

loglevel debug

logfile?/usr/local/redis/var/debug6001.log

syslog-enabled?yes

databases 16

rdbcompression?yes

dbfilename slave6001.rdb

dir?/data/redis-data/slave6001

slaveof 192.168.0.139 6001

masterauth My#redis

slave-serve-stale-data?yes

requirepass My#redis

appendonly?yes

appendfilename slave6001.aof

appendfsync everysec

no-appendfsync-on-rewrite no

vm-enabled no

vm-swap-file?/tmp/redis.swap

vm-max-memory 0

vm-page-size 32

vm-pages 134217728

vm-max-threads 4

hash-max-zipmap-entries 512

hash-max-zipmap-value 64

list-max-ziplist-entries 512

list-max-ziplist-value 64

set-max-intset-entries 512

activerehashing?yes

主庫每晚12點給每個實例手動做一次bgsave快照。主庫備份腳本（redis_bgsave.sh）

1

2

3

4

5

6

7

8

9

#!/bin/bash

#date=`date +%y%m%d_%H%M%S`

REDISPASSWORD=My#redis

for?PORT?in?`seq?6001 6010`

do

/usr/local/redis/bin/redis-cli?-h 127.0.0.1 -p $PORT -a $REDISPASSWORD bgsave

sleep?10

done

date?>>?/usr/local/redis/var/bgsave.log

從庫每晚12點拷貝每個實例的AOF到其他目錄并對其打包，壓縮包要有異地備份，之后再壓縮AOF（bgrewriteaof）。
從庫備份AOF并bgrewriteaof腳本（redis_backup.sh ：對單個實例）

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

#!/bin/sh

## FD:File Dir

## RD:Runing Dir

## 第一個參數為redis實例名

if?[ $# -ne 1 ]; then

echo?“Usage:$0? redis_name”

exit

fi

CURDATE=`date?+%Y%m%d`

CURHOUR=`date?+%Y%m%d_%H`

CURTIME=`date?+%Y%m%d_%H%M%S`

REDISPASSWORD=My#redis

REDISNAME=$1

PORT=`echo?$REDISNAME |?cut?-c6-9`

LOGFILE=/data/logs/redisbak/redis_allbak_${CURDATE}.log

if?[?"${REDISNAME}"?=?""?];?then

echo?“redis name Error!”

exit?1

else

if?[ ! -d?"/data/redis-data/${REDISNAME}"?];?then

echo?“redis name Error!”

exit?1

fi

fi

DDIR=/data/backup/redis/$CURHOUR

mkdir?-p ${DDIR}

RDIR=/data/redis-data/$REDISNAME

cd?${RDIR}

tar?-zcf $DDIR/${REDISNAME}_${CURTIME}.tar.gz $REDISNAME.aof

if?[ $? != 0 ];?then

echo?“tar?error $REDISNAME.aof” >> $LOGFILE

#exit 1

fi

sleep?5

/usr/local/redis/bin/redis-cli?-h 127.0.0.1 -p $PORT -a $REDISPASSWORD bgrewriteaof

sleep?5

###? delete old backup data dir? ###

#/bin/rm -rf `date -d -7day +”%Y%m%d”`

find?/data/backup/redis/?-mtime +7 |?xargs?rm?-rf

echo?“Backup $REDISNAME ok at $CURTIME !” >> $LOGFILE

從庫對所有實例備份（/data/sh/redis_allbak.sh）

1

2

3

4

5

6

7

#!/bin/sh

CURDATE=`date?+%Y%m%d`

LOGFILE=/data/logs/redisbak/redis_allbak_${CURDATE}.log

for?PORT?in?`seq?6001 6010`

do

/data/sh/redis_backup.sh slave${PORT} &&?echo?“slave${PORT} ok `date?+%Y%m%d_%H%M%S`” >> $LOGFILE 2>&1 ||?echo?“slave${PORT} backup error” >> $LOGFILE 2>&1

done

操作注意事項
1）若主庫掛了，不能直接開啟主庫程序。若直接開啟主庫程序將會沖掉從庫的AOF文件，這樣將導致只能恢復到前一天晚上12的備份。
2）程序在跑時，不能重啟網絡(程序是通過網絡接口的端口進行讀寫的)。網絡中斷將導致中斷期間數據丟失。
3）確定配置文件全部正確才啟動（尤其不能有數據文件名相同），否則會沖掉原來的文件，可能造成無法恢復的損失。

災難恢復
1）主庫故障，快速恢復到最近狀態描述：主庫掛了（redis程序掛了/機器宕機了），從庫正常，恢復到主庫掛掉的時間點：去從庫手動做一次快照，拷貝快照到主庫相應目錄，啟動，OK。
在從庫做一次快照，轉移快照文件到其他目錄，將快照文件目錄拷貝到主庫相應目錄，啟動主庫，OK!
( /data/sh/redis_bgsave_cp.sh )

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

#!/bin/bash

REDISPASSWORD=My#redis

for?PORT?in?`seq?6001 6010`

do

/usr/local/redis/bin/redis-cli?-h 127.0.0.1 -p $PORT -a $REDISPASSWORD bgsave

sleep?5

done

sleep?15

for?PORT?in?`seq?6001 6010`

do

SDIR=/data/redis-data/slave${PORT}/

DDIR=/data/redis_recovery/redis-data/

mkdir?-p $DDIR/redis${PORT}/

cd?$SDIR

cp?-rf slave${PORT}.rdb $DDIR/redis${PORT}/redis${PORT}.rdb

#sleep 1

done

在主庫將原來數據目錄重命名。
從從庫拷貝快照文件到主庫。
啟動主庫。

2）恢復到當天12點狀態注意備份數據（當前狀態AOF+正常退出快照）！
停止redis。
解壓AOF（/data/sh/redis_untar.sh）

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

#!/bin/bash

DAY=20111102

SDIR=/data/backup/redis/20161102_00/

cd?$SDIR

for?PORT?in?`seq?6001 6010`

do

tar?-zxf slave${PORT}_$DAY_*.tar.gz

sleep?2

done

切割AOF（/data/sh/redis_sed.sh）

#!/bin/bash

DDIR=/data/redis_recovery/

TAG=”TAG111101_1200″

for?PORT?in?`seq?6001 6010`

do

SDIR=/data/backup/redis/20161102_00/

SAOF=${SDIR}/slave${PORT}.aof

line=`sed?-n “/$TAG/=” $SAOF`

num=$[$line + 3]

mkdir?-p ${DDIR}/slave${PORT}/

sed?“${num},\$d” $SAOF > ${DDIR}/slave${PORT}/slave${PORT}.aof

done

將原來數據目錄重命名。
將切割出來的AOF目錄重命名為配置文件的數據目錄。（注釋主從同步配置項）。
啟動從庫。
做快照，拷貝到主庫，啟動主庫（同上面第1）步）。

3）恢復到兩天或幾天前12點狀態從庫每晚備份要備份AOF未bgrewriteaof之前的數據，可根據當天晚上12點備份，沒有bfrewriteaof之前的AOF文件來進行恢復，方法同上面的第2）步。

?

?

公司線上redis主從環境下的持久化策略調整：
描述：
之前線上項目使用redis，部署了redis主從環境。redis的主從復制功能非常強大，一個master可以擁有多個slave，而一個slave又可以擁有多個slave，如此下去，形成了強大的多級服務器集群架構。由于主redis采用了AOF和save快照的持久化，長時間下去，aof文件不斷增大，磁盤空間使用率逐漸暴增。
考慮到性能問題，需要對redis持久化做些調整，調整如下：
? ?1）主庫不開啟AOF持久化，并關閉save快照功能（即注釋默認的三個save設置），只在每晚12點定時手動做一次bgsave快照，并將快照文件轉移到異地。即主庫上不產生appendonly.aof持久化文件，做的快照數據放在.rdb文件里（如dump.rdb，由于是壓縮配置(rdbcompression yes表示快照文件要壓縮)，所以快照文件要比aof文件小），然后將這個快照文件dump.rdb轉移到其他的服務器上，防止主服務器宕機造成的損失！
? ?2）從庫開啟AOF持久化并1秒落地，同樣不做快照save。并在每晚12點做一次bgrewriteaof壓縮appendonly.aof持久化文件，壓縮前先對aof文件進行備份。
--------------------------------------------------------------------------------------------------------------------------------------------
按照這種方法進行redis持久化調整，由于線上redis的主庫之前采用了AOF和save快照的持久化，之后將這兩種都關閉，從庫采用AOF持久化。出現了下面的現象：
就是主庫關閉AOF和save快照后，主redis上的appendonly.aof持久化文件在一段時間內還在刷，在增大，這是正常的，由于之前開啟的緣故，刷過一段時間，主redis的appendonly.aof持久化文件就不刷了，只有從redis的appendonly.aof持久化文件在刷了
--------------------------------------------------------------------------------------------------------------------------------------------

主從redis部署的主要目的：數據持久化，災難恢復，冗余。主庫不落地，減少消耗。
1）主庫不做AOF，不做快照，允許從庫訪問即可。
2）從庫開啟AOF，不做save
3）備份策略：
主庫每晚12點整給每個實例手動做一次bgsave快照，并將快照文件備份到遠程節點上。
從庫每晚12點整對AOF文件打包備份(tar)，打包備份后做一次AOF文件壓縮(bgrewriteaof)。每天的數據起始點是前一天晚上rewriteaof后的數據。

主庫服務器腳本：
即主庫快照之后，將快照文件轉移到異地即從庫機器192.168.1.121/135上面。

1

2

3

4

5

6

7

8

9

[root@192-168-1-132 redis]# cat redis_bgsave.sh

#!/bin/bash

CURHOUR=`date?+%Y%m%d_%H`

/usr/local/bin/redis-cli?-h 127.0.0.1 -p 6379 bgsave

sleep?10

rsync?-av?/data/redis/dump.rdb root@192.168.1.121:/data/backup/192.168.1.132-save/$CURHOUR/

rsync?-av?/data/redis/dump.rdb root@192.168.1.135:/data/backup/192.168.1.132-save/$CURHOUR/

sleep?10

date?>>?/data/logs/bgsave.log

從庫服務器腳本：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

[root@cdn redis]# cat redis_backup.sh

#!/bin/bash

?

CURDATE=`date?+%Y%m%d`

CURHOUR=`date?+%Y%m%d_%H`

CURTIME=`date?+%Y%m%d_%H%M%S`

LOGFILE=/data/logs/redisbak/redis_allbak_${CURDATE}.log

REDISNAME=appendonly.7000

DDIR=/data/backup/redis/$CURHOUR

mkdir?-p ${DDIR}

RDIR=/data/redis

cd?${RDIR}

tar?-zcf $DDIR/${REDISNAME}_${CURTIME}.tar.gz appendonly.7000.aof

if?[ $? != 0 ];?then

??echo?"tar error $REDISNAME.aof"?>> $LOGFILE

fi

sleep?5

/usr/local/bin/redis-cli?-h 127.0.0.1 -p 6379 bgrewriteaof

sleep?5

?

###? delete old backup data dir? ###

#/bin/rm -rf `date -d -30day + "%Y%m%d"`

find?/data/backup/redis/?-mtime +30 |?xargs?rm?-rf

echo?"Backup $REDISNAME ok at $CURTIME !"?>> $LOGFILE

[root@cdn redis]# crontab -e
59 23 * * * /bin/bash /data/redis/redis_backup.sh >/dev/null 2>&1

[root@cdn redis]# cd /data/backup/redis/20161207_13
[root@cdn 20161207_13]# ls
appendonly.7000_20161207_133131.tar.gz

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/news/535340.shtml
繁體地址，請注明出處：http://hk.pswp.cn/news/535340.shtml
英文地址，請注明出處：http://en.pswp.cn/news/535340.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

Redis哨兵模式（sentinel）學習總結及部署記錄（主從復制、讀寫分離、主從切換）

Redis哨兵模式（sentinel）學習總結及部署記錄（主從復制、讀寫分離、主從切換）

Redis的集群方案大致有三種：1）redis cluster集群方案；2）master/slave主從方案；3）哨兵模式來進行主從替換以及故障恢復。 一、sentinel哨兵模式介紹 Sentinel(哨兵)是用于監控redis集群中Master狀態的工具&…
閱讀更多...
Redis之Redis內存模型

Redis之Redis內存模型

Redis是目前最火爆的內存數據庫之一，通過在內存中讀寫數據，大大提高了讀寫速度，可以說Redis是實現網站高并發不可或缺的一部分。 我們使用Redis時，會接觸Redis的5種對象類型（字符串、哈希、列表、集合、有序集合&…
閱讀更多...
MySQL 數據庫誤刪除后的數據恢復操作說明

MySQL 數據庫誤刪除后的數據恢復操作說明

在日常運維工作中，對mysql數據庫的備份是萬分重要的，以防在數據庫表丟失或損壞情況出現，可以及時恢復數據。 線上數據庫備份場景： 每周日執行一次全量備份，然后每天下午1點執行MySQLdump增量備份. 下面對這種備份方案…
閱讀更多...
MySQL 之binlog日志說明及利用binlog日志恢復數據操作記錄

MySQL 之binlog日志說明及利用binlog日志恢復數據操作記錄

眾所周知，binlog日志對于mysql數據庫來說是十分重要的。在數據丟失的緊急情況下，我們往往會想到用binlog日志功能進行數據恢復（定時全備份binlog日志恢復增量數據部分），化險為夷！ 一、簡單了解binlog MySQ…
閱讀更多...
zabbix巡檢腳本

zabbix巡檢腳本

#!/bin/bash BIN/usr/local/zabbix/binpasswort() { name$2 while read line do ipecho $line|awk -F {print $1} timeecho $line|awk -F {print $2} echo -e "${name}passport${ip}探活時間\t $time" done <$1 }for i in 100.245.160.113 100.245.160.141 1…
閱讀更多...
mysqldump備份（全量+增量）

mysqldump備份（全量+增量）

在日常運維工作中&#xff0c;對mysql數據庫的備份是萬分重要的&#xff0c;以防在數據庫表丟失或損壞情況出現&#xff0c;可以及時恢復數據。 線上數據庫備份場景&#xff1a; 每周日執行一次全量備份&#xff0c;然后每天下午1點執行MySQLdump增量備份. 下面對這種備份方案…
閱讀更多...
查找指定日期數據所在分區數據

查找指定日期數據所在分區數據

select a.subobject_namefrom dba_objects a join (select dbms_rowid.rowid_object(rowid) object_idfrom NEWLOG4 where TO_CHAR(autudt,YYYY-MM-DD) 2021-06-22) b on a.object_id b.object_id and object_name UPPER(NEWLOG4) group by a.subobject_name
閱讀更多...
統計內存使用率shell

統計內存使用率shell

#!/bin/bashdatedate "%Y-%m-%d %H:%M:%S"#顯示消耗資源內存最高的進程名firstps aux | grep -v "grep" | grep -v "USER" | sort -rn -k 4 | head -4 | awk -F {print $13} | sed -n 1pSecondps aux | grep -v "grep" | grep -v &q…
閱讀更多...
Oracle 11g系統自動收集統計信息

Oracle 11g系統自動收集統計信息

從Oracle Database 10g開始&#xff0c;Oracle在建庫后就默認創建了一個名為GATHER_STATS_JOB的定時任務&#xff0c;用于自動收集CBO的統計信息&#xff0c;調用DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC收集統計信息。該過程首先檢測統計信息缺失和陳舊的對象。然后確定優先…
閱讀更多...
Redis監控指標

Redis監控指標

監控指標 ?性能指標&#xff1a;Performance?內存指標: Memory?基本活動指標&#xff1a;Basic activity?持久性指標: Persistence?錯誤指標&#xff1a;Error 性能指標&#xff1a;Performance NameDescriptionlatencyRedis響應一個請求的時間instantaneous_ops_per_s…
閱讀更多...
innobackupex參數說明

innobackupex參數說明

1、備份&#xff1a; #常用參數 　　　　--user&#xff1a;該選項表示備份賬號。 　　　　--password&#xff1a;該選項表示備份的密碼。 　　　　--port&#xff1a;該選項表示備份數據庫的端口。 　　　　--host&#xff1a;該選項表示備份數據庫的地址。 　　　　--socket…
閱讀更多...
innobackupex遠程備份腳本

innobackupex遠程備份腳本

#!/bin/sh #備份主機 remote_ip10.2.142.161 Master_ip10.2.142.148 VIP103.2.132.136 #備份用戶 userroot #密碼 password123456 # 返回年月日 backup_datedate %F # 返回時分秒 backup_timedate %H-%M-%S # 返回今天是這周的第幾天 backup_week_daydate %u backup_ok0 #備份目…
閱讀更多...
MySQL管理利器 MySQL Utilities---mysqlreplicate

MySQL管理利器 MySQL Utilities---mysqlreplicate

mysqlreplicate 工具是在兩臺服務器間設置和啟動復制。用戶提供登錄從服務器信息和連接到主的信息。也可以指定一個數據庫用于測試復制。 該工具報告條件是當主和從的存儲引擎不一樣時。如果主和從的存儲引擎不同將產生告警信息。對于Innodb存儲引擎而言&#xff0c;必需完全…
閱讀更多...
MySQL管理工具MySQL Utilities — 如何連接MySQL服務器

MySQL管理工具MySQL Utilities — 如何連接MySQL服務器

連接參數 連接到一個服務器&#xff0c;必須指定連接參數&#xff0c;如用戶名&#xff0c;主機名稱&#xff0c;密碼&#xff0c;端口號&#xff0c;socket。MySQL Utilities提供了三種提供這些參數的方法&#xff0c;這些方法都需要通過命令行指定。 使用.mylogin.cnf文件&…
閱讀更多...
MHA高可用

MHA高可用

manager 組件 masterha_manger # 啟動MHA masterha_check_ssh # 檢查MHA的SSH配置狀況 masterha_check_repl # 檢查MySQL復制狀況&#xff0c;配置信息 masterha_master_monitor # 檢測master是否宕機 masterha_check_status # 檢測當…
閱讀更多...
MySQL Replication需要注意的問題

MySQL Replication需要注意的問題

主庫意外宕機 如果沒有設置主庫的sync_binlog選項&#xff0c;就可能在奔潰前沒有將最后的幾個二進制日志事件刷新到磁盤中。備庫I/O線程因此也可一直處于讀不到尚未寫入磁盤的事件的狀態中。當主庫從新啟動時&#xff0c;備庫將重連到主庫并再次嘗試去讀該事件&#xff0c;但…
閱讀更多...
update和delete操作忘加where條件導致全表更新的處理方法

update和delete操作忘加where條件導致全表更新的處理方法

在數據庫日常維護中&#xff0c;開發人員是最讓人頭痛的&#xff0c;很多時候都會由于SQL語句寫的有問題導致服務器出問題&#xff0c;導致資源耗盡。最危險的操作就是在做DML操作的時候忘加where條件&#xff0c;導致全表更新&#xff0c;這是作為運維或者DBA的我們改如何處理…
閱讀更多...
Innodb結構

Innodb結構

從MySQL5.5版本開始默認使用InnoDB作為引擎&#xff0c;它擅長處理事務&#xff0c;具有自動崩滿恢復的特性&#xff0c;在日常開發中使用非常廣泛&#xff0c;下面是言方的InnoDB引擎美構圖&#xff0c;主要分為內存結構和磁盤結構兩大部分。 內存結構主要包括Buffer Pool、C…
閱讀更多...
ES備份工具elasticdump

ES備份工具elasticdump

安裝 下載node下載 | Node.js 中文網 tar xvf node-v16.5.0-linux-x64.tar.xz ln -s /app/temp/node-v16.5.0-linux-x64/bin/node /usr/bin/node ln -s /app/temp/node-v16.5.0-linux-x64/bin/npm /usr/bin/npm npm install elasticdump -g npm config get cache npm in…
閱讀更多...
innodb_flush_method理解【轉】

innodb_flush_method理解【轉】

innodb_flush_method這個參數控制著innodb數據文件及redo log的打開、刷寫模式&#xff0c;對于這個參數&#xff0c;文檔上是這樣描述的&#xff1a; 有三個值&#xff1a;fdatasync(默認)&#xff0c;O_DSYNC&#xff0c;O_DIRECT 默認是fdatasync&#xff0c;調用fsync()去…
閱讀更多...
最新文章

Copyright @ 2022~2023