redis6持久化主从复制
?
redis持久化
理論
1、?RDB持久化（默認支持，無需配置）
該機制是指在指定的時間間隔內將內存中的數據集快照寫入磁盤。
2、?AOF持久化
該機制將以日志的形式記錄服務器所處理的每一個寫操作，在Redis服務器啟動之初會讀取該文件來重新構建數據庫，以保證啟動后數據庫中的數據是完整的。
3、?無持久化
我們可以通過配置的方式禁用Redis服務器的持久化功能，這樣我們就可以將Redis視為一個功能加強版的memcached了。
4、?redis同時使用RDB和AOF
7.1.1?RDB
7.1.1.1?優勢
1、?一旦采用該方式，那么你的整個Redis數據庫將只包含一個文件，這對于文件備份而言是非常完美的。比如，你可能打算每個小時歸檔一次最近24小時的數據，同時還要每天歸檔一次最近30天的數據。通過這樣的備份策略，一旦系統出現災難性故障，我們可以非常容易的進行恢復。
2、?對于災難恢復而言，RDB是非常不錯的選擇。因為我們可以非常輕松的將一個單獨的文件壓縮后再轉移到其它存儲介質上
3、?性能最大化。對于Redis的服務進程而言，在開始持久化時，它唯一需要做的只是fork出子進程，之后再由子進程完成這些持久化的工作，這樣就可以極大的避免服務進程執行IO操作了。
4、?相比于AOF機制，如果數據集很大，RDB的啟動效率會更高。
7.1.1.2?劣勢
1、?如果你想保證數據的高可用性，即最大限度的避免數據丟失，那么RDB將不是一個很好的選擇。因為系統一旦在定時持久化之前出現宕機現象，此前沒有來得及寫入磁盤的數據都將丟失。
2、?由于RDB是通過fork子進程來協助完成數據持久化工作的，因此，如果當數據集較大時，可能會導致整個服務器停止服務幾百毫秒，甚至是1秒鐘
7.1.1.3?配置說明Snapshotting
l?save 900 1 #每900秒(15分鐘)至少有1個key發生變化，則dump內存快照。
l?save 300 10 #每300秒(5分鐘)至少有10個key發生變化，則dump內存快照
l?save 60 10000 #每60秒(1分鐘)至少有10000個key發生變化，則dump內存快照
7.1.2?AOF
7.1.2.1?優勢
1、?該機制可以帶來更高的數據安全性，即數據持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事實上，每秒同步也是異步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那么這一秒鐘之內修改的數據將會丟失。而每修改同步，我們可以將其視為同步持久化，即每次發生的數據變化都會被立即記錄到磁盤中。可以預見，這種方式在效率上是最低的。至于無同步，無需多言，我想大家都能正確的理解它。
2、?由于該機制對日志文件的寫入操作采用的是append模式，因此在寫入過程中即使出現宕機現象，也不會破壞日志文件中已經存在的內容。然而如果我們本次操作只是寫入了一半數據就出現了系統崩潰問題，不用擔心，在Redis下一次啟動之前，我們可以通過redis-check-aof工具來幫助我們解決數據一致性的問題。
3、?如果日志過大，Redis可以自動啟用rewrite機制。即Redis以append模式不斷的將修改數據寫入到老的磁盤文件中，同時Redis還會創建一個新的文件用于記錄此期間有哪些修改命令被執行。因此在進行rewrite切換時可以更好的保證數據安全性。
4、?AOF包含一個格式清晰、易于理解的日志文件用于記錄所有的修改操作。事實上，我們也可以通過該文件完成數據的重建
?
?
?
222配置AOF
@怎么開啟
appendonly yes：開啟AOF?
@什么方式
# appendfsync always
appendfsync everysec
# appendfsync no
l?always????#每次有數據修改發生時都會寫入AOF文件
l?everysec? #每秒鐘同步一次，該策略為AOF的缺省策略
l?no?????? #從不同步。高效但是數據不會被持久化
?
從 Redis 2.4 開始，AOF 重寫由 Redis 自行觸發， BGREWRITEAOF 僅僅用于手動觸發重寫操作。但網上有網友說已經3.2.5版本了，貌似redis還是沒有自動觸發BGREWRITEAOF
?
數據恢復演示
1、?flushall操作? 清空數據庫
2、?及時關閉redis服務器（防止dump.rdb）。??shutdown nosave? ///在 redis-celi 關閉redis 服務
3、?編輯aof文件(vim)，將日志中的flushall命令刪除并重啟服務即可
?
?
redis-check-aof 檢查工具
redis-check-aof /usr/local/var/db/redis/appendonly.aof
AOF analyzed: size=79, ok_up_to=79, diff=0
AOF is valid
?
重寫AOF：若不滿足重寫條件時，可以手動重寫，命令：bgrewriteaof
執行一個 AOF文件重寫操作，重寫會創建一個當前 AOF 文件的體積優化版本。
即使 BGREWRITEAOF 執行失敗，也不會有任何數據丟失，因為舊的 AOF 文件在 BGREWRITEAOF 成功之前不會被修改。
從 Redis 2.4 開始，AOF 重寫由 Redis 自行觸發， BGREWRITEAOF 僅僅用于手動觸發重寫操作。但網上有網友說已經3.2.5版本了，貌似redis還是沒有自動觸發BGREWRITEAOF
穩妥的方法還寫一個腳本每天定時去執行
?
1? BGSAVE（保存dump.rdb)手動讓 Redis 進行數據集保存操作
自動保存一次數據集。你也可以通過調用 SAVE 或者 BGSAVE ， 手動讓 Redis 進行數據集保存操作
2BGREWRITEAOF(重寫AOF文件
?在版本號大于等于 2.4 的 Redis 中， BGSAVE（保存dump.rdb） 執行的過程中， 不可以執行 BGREWRITEAOF(重寫AOF文件) 。 反過來說， 在 BGREWRITEAOF 執行的過程中， 也不可以執行 BGSAVE 。
?
?
?
怎么把一個dump.rdb文件生成一個AOF文件
1? BGSAVE（保存dump.rdb)手動讓 Redis 進行數據集保存操作
自動保存一次數據集。你也可以通過調用 SAVE 或者 BGSAVE ， 手動讓 Redis 進行數據集保存操作
2BGREWRITEAOF(重寫AOF文件
?
在版本號大于等于 2.4 的 Redis 中， BGSAVE（保存dump.rdb） 執行的過程中， 不可以執行 BGREWRITEAOF(重寫AOF文件) 。 反過來說， 在 BGREWRITEAOF 執行的過程中， 也不可以執行 BGSAVE 。
?
?
?
?
?
?
?
?
?
?
?
主從復制
主從復制的配置
# slaveof <masterip ip 地址> <masterport端口>//將當前server做為slave,并為其指定master信息.
安全
# requirepass foobared
任何客戶端或者slave與此server交互前,需要提交密碼,其他server的masterauth配置和此參數值保持一致
密碼應該足夠復雜(64字節)
?
怎么填寫密碼 auth gu
?
?
288 # masterauth <master-password>
“requirepass”配置項指定了當前server的密碼。
此配置項中<master-password>值需要和master機器的”requirepass”保持一致
301 slave-serve-stale-data yes
如果當前server是slave,那么當slave與master失去通訊時,是否繼續為客戶端提供服務,”yes”表示繼續,”no”表示終止.
- 在”yes”情況下,slave繼續向客戶端提供只讀服務,有可能此時的數據已經過期.
- 在”no”情況下,任何向此server發送的數據請求服務(包括客戶端和此server的slave)都將被告知”error”
?
主從復制
1、?復制一份redis.conf文件并修改名稱，如：cp redis.conf redis6380.conf
2、?修改redis6380.conf文件中的
l?端口號
l?進程id號（pidfile /var/run/redis6380.pid）
l?slaveof：主從復制信息
l?存放aof、rdb文件的目錄。
轉載于:https://www.cnblogs.com/keiweila/p/7879049.html
總結
以上是生活随笔為你收集整理的redis6持久化主从复制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： M码小黄衫买家秀=w=
- 下一篇： 【Jmeter自学】badboy使用（三