目錄
介紹
基本主從複制
Redis主機配置
Redis從機配置
改變從=>主角色
Redis哨兵
運作哨兵
Redis 哨兵自動故障轉移
相關連結
第一部分—— Redis:複制,第1部分——概述 複制與分片、哨兵與叢集、Redis拓撲。
介紹
當我們決定擺脫memcached時,整個故事就開始了。
目前,我們已經在我們的後端伺服器上運作memcahced和Redis。
并且memcached,Redis執行個體作為獨立應用程式運作,即它們沒有連接配接任何類型的複制,這導緻了一個問題:
- 我們有三個後端主機,它們托管在AWS應用負載平衡器後面
- ALB 啟用了Sticky Sessions,但它正在使用我們的移動應用程式(iOS / Android)忽略的cookie
- 當用戶端向後端送出請求時——有時,它可以擷取已在Redis中的另一個後端主機上删除/更新的緩存資料或 memcached
我們有這個方案,因為我們從一個舊的基礎設施遷移我們的後端應用程式,其中隻使用了一個主機并且仍然沒有時間更新它,盡管它在我們的主機上很長一段時間了。
目前,為了解決這些問題,我們在後端有一堆“黑客”,它會進行額外的檢查以確定資料是最新的,現在為了擺脫它們,我們決定:
- 完全擺脫memcached,因為Redis可以用于現在memcached使用的功能
- 在所有主機上配置Redis複制
這樣的設定将在下面的内容中描述。
第一個示例——使用基本的主從複制和第二個示例——哨兵設定和配置。
這裡将使用Debian 9的AWS EC2執行個體。
要與Redis主機一起使用,将使用三個域名——redis-0.setevoy.org.ua用于主伺服器,redis-1.setevoy.org.ua和redis-2.setevoy.org.ua用于其兩個從伺服器。
最小設定中的從機隻能是一個,但這裡的第二個例子将是哨兵——讓我們從一開始就有三個。
基本主從複制
這樣,從機将成為主機的隻讀從機,保留将添加到主機中的相同資料。
主機将向其從機發送所有資料更新——新密鑰到期等。
如果主機和從機之間的鍊路斷開——從機将嘗試重新連接配接到主機并進行部分同步以從先前同步被中斷的位置更新資料。
如果不能進行這種部分同步——從機将要求主機進行完全同步,并且主機将執行其資料完整快照,該快照将被發送到該從機,此後,将恢複通常的同步。
這裡有幾點需要注意:
- 一個主機可以擁有多個從機
- 從機可以接受來自其他從機的連接配接,使得複制節點的“級聯”——頂部的主機,中間的從機和底部的從機
- 強烈建議在主伺服器上啟用資料持久性以避免資料丢失——請參閱主伺服器關閉持久性時的複制安全性
- 預設情況下,從機将以隻讀模式工作,請參閱隻讀從機
Redis主機配置
安裝Redis:
[email protected]:/home/admin# apt -y install redis-server
編輯/etc/redis/redis.conf并在bind集接口中監聽:
...
bind 0.0.0.0
...
您可以在此處指定以空格分隔的多個IP:.
...
bind 127.0.0.1 18.194.229.23
...
其他有價值的選擇:
- port 6379——足夠清楚但記住它
- slave-read-only yes——從機将以隻讀模式工作,不會影響主機
- requirepass foobared ——主機授權的密碼
- appendonly yes和appendfilename "appendonly.aof"——減少資料丢失的機會,詳見Redis的持久性
重新開機服務:
[email protected]:/home/admin# systemctl restart redis
使用-a密碼檢查:
[email protected]:/home/admin# redis-cli -a foobared ping
PONG
檢查資料複制狀态:
[email protected]:/home/admin# redis-cli -a foobared info replication
Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
添加新資料:
[email protected]:/home/admin# redis-cli -a foobared set test 'test'
OK
傳回資料:
[email protected]:/home/admin# redis-cli -a foobared get test
"test"
好的——這裡一切正常。
Redis從機配置
在左側的兩台主機上,進行從機配置。
兩者都是一樣的——隻需重複一遍即可。
安裝Redis:
[email protected]:/home/admin# apt -y install redis-server
編輯/etc/redis/redis.conf:
...
slaveof redis-0.setevoy.org.ua 6379
...
masterauth foobared
...
requirepass foobared
...
這裡:
- slaveof——設定主伺服器的主機和端口
- masterauth——主機的認證
- requirepass——在此從機上驗證
重新開機服務:
[email protected]:/home/admin# systemctl restart redis
檢查其狀态:
[email protected]:/home/admin# redis-cli -a foobared info replication
Replication
role:slave
master_host:redis-0.setevoy.org.ua
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
...
檢查日志:
[email protected]:/home/admin# tail -f /var/log/redis/redis-server.log
16961:S 29 Mar 10:54:36.263 * Connecting to MASTER redis-0.setevoy.org.ua:6379
16961:S 29 Mar 10:54:36.308 * MASTER <-> SLAVE sync started
16961:S 29 Mar 10:54:36.309 * Non blocking connect for SYNC fired the event.
16961:S 29 Mar 10:54:36.309 * Master replied to PING, replication can continue...
16961:S 29 Mar 10:54:36.310 * Partial resynchronization not possible (no cached master)
16961:S 29 Mar 10:54:36.311 * Full resync from master: 93585eeb7e32c0550c35f8d4935c9a18c4177ab9:1
16961:S 29 Mar 10:54:36.383 * MASTER <-> SLAVE sync: receiving 92 bytes from master
16961:S 29 Mar 10:54:36.383 * MASTER <-> SLAVE sync: Flushing old data
16961:S 29 Mar 10:54:36.383 * MASTER <-> SLAVE sync: Loading DB in memory
16961:S 29 Mar 10:54:36.383 * MASTER <-> SLAVE sync: Finished with success
建立連接配接到主機,同步完成——好吧,檢查資料:
[email protected]:/home/admin# redis-cli -a foobared get test
"test"
資料存在——這裡所有工作都正常運作。
改變從=>主角色
如果主機将關閉——您必須切換其中一個從機成為新的主機。
如果您嘗試在目前從機上添加任何資料——由于從機處于隻讀模式,Redis将引發錯誤:
...
slave-read-only yes
...
嘗試添加一些東西:
[email protected]:/home/admin# redis-cli -a foobared set test2 'test2'
(error) READONLY You can't write against a read only slave.
現在連接配接到從機:
[email protected]:/home/admin# redis-cli
授權:
127.0.0.1:6379> auth foobared
OK
禁用slave-role:
127.0.0.1:6379> slaveof no one
OK
立即檢查其狀态:
127.0.0.1:6379> info replication
Replication
role:master
connected_slaves:0
master_repl_offset:1989
repl_backlog_active:0
repl_backlog_size:1048576
再次添加新密鑰:
127.0.0.1:6379> set test2 'test2'
OK
得到傳回值:
127.0.0.1:6379> get test2
"test2"
請記住,我們直接在Redis節點中進行了這些更改——重新啟動後,它将再次成為從屬伺服器,因為它仍然在其/etc/redis/redis.conf檔案中使用slaveof參數進行設定。
Redis哨兵
現在讓我們将哨兵添加到我們的複制中,它将監視Redis節點并自動執行角色切換。
整個計劃将是下一個:
這裡:
- M1 =主機
- R1 =複制 1 /從機1
- R2 =複制 2 /從機2
- S1 =哨兵 1
- S2 =哨兵 2
- S3 =哨兵 3
M1和S1——将對應redis-0,R 1和S2——對應redis -1,R 2和S3——對應redis-2。
運作哨兵
要運作哨兵守護程式,redis-server隻能使用單獨的配置——/etc/redis/哨兵.conf。
首先,讓我們在Redis Master主機上建立這樣的配置檔案:
sentinel monitor redis-test redis-0.setevoy.org.ua 6379 2
sentinel down-after-milliseconds redis-test 6001
sentinel failover-timeout redis-test 60000
sentinel parallel-syncs redis-test 1
bind 0.0.0.0
sentinel auth-pass redis-test foobared
這裡:
- Monitor——要監視的主機位址,2是哨兵的執行個體編号來決定
- down-after-milliseconds——主機将被視為無序的時間
- failover-timeout——更改從機=> 主機角色後等待的時間
- parallel-syncs——主機更改後同步從機的數目
運作:
[email protected]:/home/admin# redis-server /etc/redis/sentinel.conf --sentinel
...
10447:X 29 Mar 14:15:53.193 # WARNING: The TCP backlog setting of 511 cannot be enforced
because /proc/sys/net/core/somaxconn is set to the lower value of 128.
10447:X 29 Mar 14:15:53.195 # Sentinel ID is e9fb72c8edb8ec2028e6ce820b9e72e56e07cf1e
10447:X 29 Mar 14:15:53.195 # +monitor master redis-test 35.158.154.25 6379 quorum 2
10447:X 29 Mar 14:15:53.196 * +slave slave 3.121.223.95:6379 3.121.223.95 6379
@ redis-test 35.158.154.25 6379
10447:X 29 Mar 14:16:43.402 * +slave slave 18.194.45.17:6379 18.194.45.17 6379
@ redis-test 35.158.154.25 6379
使用26379端口檢查哨兵的狀态:
[email protected]:/home/admin# redis-cli -p 26379 info sentinel
Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=redis-test,status=ok,address=35.158.154.25:6379,slaves=2,sentinels=1
這裡:
- master0:name=redis-test,status=ok——主機是UP
- slaves=2——它有兩個從機
- 哨兵s=1——目前隻運作一個哨兵執行個體
您可以在這裡獲得一些基本資訊,例如——主機的IP:
[email protected]:/home/admin# redis-cli -p 26379 sentinel get-master-addr-by-name redis-test
1) "35.158.154.25"
2) "6379"
現在使用與我們在主機和哨兵日志中執行的配置相同的配置重複兩個從機上的哨兵啟動,您必須看到連接配接的新執行個體:
...
10447:X 29 Mar 14:18:40.437 * +sentinel sentinel fdc750c7d6388a6142d9e27b68172f5846e75d8c
172.31.36.239 26379 @ redis-test 35.158.154.25 6379
10447:X 29 Mar 14:18:42.725 * +sentinel sentinel ecddb26cd27c9a17c4251078c977761faa7a3250
172.31.35.218 26379 @ redis-test 35.158.154.25 6379
...
再次檢查狀态:
[email protected]:/home/admin# redis-cli -p 26379 info sentinel
Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=redis-test,status=ok,address=18.194.229.23:6379,slaves=2,sentinels=3
哨兵s=3——好的。
此外,哨兵将在需要時執行自己的設定更新:
[email protected]:/home/admin# cat /etc/redis/sentinel.conf
sentinel myid fdc750c7d6388a6142d9e27b68172f5846e75d8c
sentinel monitor redis-test 35.158.154.25 6379 2
sentinel down-after-milliseconds redis-test 6001
bind 0.0.0.0
sentinel failover-timeout redis-test 60000
Generated by CONFIG REWRITE
port 26379
dir "/home/admin"
sentinel auth-pass redis-test foobared
sentinel config-epoch redis-test 0
sentinel leader-epoch redis-test 0
sentinel known-slave redis-test 18.194.45.17 6379
sentinel known-slave redis-test 3.121.223.95 6379
sentinel known-sentinel redis-test 172.31.35.218 26379 ecddb26cd27c9a17c4251078c977761faa7a3250
sentinel known-sentinel redis-test 172.31.47.184 26379 e9fb72c8edb8ec2028e6ce820b9e72e56e07cf1e
sentinel current-epoch 0
這是添加的哨兵myid fdc750c7d6388a6142d9e27b68172f5846e75d8c以及#CONFIG REWRITE生成的整個塊。
Redis 哨兵自動故障轉移
現在讓我們來看看如果主機會失敗将會發生什麼。
您可以通過調用kill -9或使用redis-cli和以及DEBUG以秒為機關發送指令來手動執行此操作,以使主機“關閉”或通過發送信号來殺死主機。
[email protected]:/home/admin# redis-cli -a foobared DEBUG sleep 30
哨兵登入主機:
...
10447:X 29 Mar 14:24:56.549 # +sdown master redis-test 35.158.154.25 6379
10447:X 29 Mar 14:24:56.614 # +new-epoch 1
10447:X 29 Mar 14:24:56.615 # +vote-for-leader ecddb26cd27c9a17c4251078c977761faa7a3250 1
10447:X 29 Mar 14:24:56.649 # +odown master redis-test 35.158.154.25 6379 #quorum 3/2
10447:X 29 Mar 14:24:56.649 # Next failover delay:
I will not start a failover before Fri Mar 29 14:26:57 2019
10447:X 29 Mar 14:24:57.686 # +config-update-from sentinel
ecddb26cd27c9a17c4251078c977761faa7a3250 172.31.35.218 26379 @ redis-test 35.158.154.25 6379
10447:X 29 Mar 14:24:57.686 # +switch-master redis-test 35.158.154.25 6379 3.121.223.95 6379
10447:X 29 Mar 14:24:57.686 * +slave slave 18.194.45.17:6379 18.194.45.17 6379
@ redis-test 3.121.223.95 6379
10447:X 29 Mar 14:24:57.686 * +slave slave 35.158.154.25:6379 35.158.154.25 6379
@ redis-test 3.121.223.95 6379
10447:X 29 Mar 14:25:03.724 # +sdown slave 35.158.154.25:6379 35.158.154.25 6379
@ redis-test 3.121.223.95 6379
...
目前,我們對這兩行感興趣:
...
10384:X 29 Mar 14:24:57.686 # +config-update-from sentinel
ecddb26cd27c9a17c4251078c977761faa7a3250 172.31.35.218 26379 @ redis-test 35.158.154.25 6379
10384:X 29 Mar 14:24:57.686 # +switch-master redis-test 35.158.154.25 6379 3.121.223.95 6379
...
哨兵執行從機到主機的重新配置。
35.158.154.25——現在已經死了的老主機,3.121.223.95是從從機中選出的新主機——它在redis-1主機上運作。
嘗試在此處添加資料:
[email protected]:/home/admin# redis-cli -a foobared set test3 'test3'
OK
當對現在成為從機的舊主機進行類似的嘗試時,将導緻錯誤:
[email protected]:/home/admin# redis-cli -a foobared set test4 'test4'
(error) READONLY You can't write against a read only slave.
讓我們殺死一個節點,看看哨兵現在會做什麼:
[email protected]:/home/admin# redis-cli -a foobared DEBUG SEGFAULT
Error: Server closed the connection
日志:
...
10447:X 29 Mar 14:26:21.897 * +reboot slave 35.158.154.25:6379 35.158.154.25 6379
@ redis-test 3.121.223.95 6379
嗯——哨兵剛剛重新開機了那個節點
哨兵指令
指令 | 描述 |
sentinel masters | 列出所有主機及其狀态 |
sentinel master | 一個主機的身份 |
sentinel slaves | 列出所有從機及其狀态 |
sentinel sentinels | 列出所有哨兵執行個體及其狀态 |
sentinel failover | 手動運作故障轉移 |
sentinel flushconfig | 強制哨兵重寫其在磁盤上的配置 |
sentinel monitor | 添加一個新的主機 |
sentinel remove | 從被檢測中移除主機 |
相關連結
- Redis複制
- Примерфайланастроек哨兵
- Redis哨兵——高可用性:從DEV到PROD需要了解的所有内容:完整指南
- Redis哨兵:使您的資料集具有高可用性
- 如何運作Redis哨兵
原文位址:https://www.codeproject.com/Articles/1328499/Redis-Replication-Part-2-Master-Slave-Replication