【Azure Redis 快取】由Azure Redis是否可以自定義密碼而引申出Azure PaaS的Redis服務是否可以和自建的Redis進行主從配置呢？

路邊兩盞燈發表於2021-06-21
Redis快取密碼

問題描述

 在自建的Redis服務中，可以通過 config set requirepass <Password> 設定Redis的登入密碼，然後使用auth 命令輸入密碼。操作命令如下：

##設定密碼
C:\LBWorkSpace\tool\redis>redis-cli

127.0.0.1:6379> config set requirepass Password@123
OK
127.0.0.1:6379> quit

##重新連線到Redis伺服器
C:\LBWorkSpace\tool\redis>redis-cli
127.0.0.1:6379> ping
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth Password@123
OK
127.0.0.1:6379> ping
PONG
127.0.0.1:6379>

 

那麼在Azure 的Redis服務中，是否也可以使用者自定義密碼呢？

 

問題分析

在Redis中，設定密碼使用的指令為CONFIG SET requirepass, 根據Azure 官方文件，CONFIG命令被禁止。所以無法實現自定義密碼。只能根據Redis門戶的Access Key中生成隨機的一串金鑰，由Azure平臺提供。

 

在Azure Redis中執行CONFIG SET REQUIREPASS 會得到ERR unknown command  

【Azure Redis 快取】由Azure Redis是否可以自定義密碼而引申出Azure PaaS的Redis服務是否可以和自建的Redis進行主從配置呢？

 

在Azure門戶中生成金鑰

【Azure Redis 快取】由Azure Redis是否可以自定義密碼而引申出Azure PaaS的Redis服務是否可以和自建的Redis進行主從配置呢？

 

重要

因為 Azure Redis 快取例項的配置和管理由 Microsoft 進行管理，所以禁用了以下命令。 如果嘗試呼叫它們，將收到一條類似於 "(error) ERR unknown command" 的錯誤訊息。

  • BGREWRITEAOF
  • BGSAVE
  • CONFIG
  • DEBUG
  • MIGRATE
  • SAVE
  • SHUTDOWN
  • SLAVEOF
  • CLUSTER - 群集寫命令已禁用，但允許使用只讀群集命令。

引申問題

因為Azure Redis不能讓使用者自定義密碼，所以當兩個Redis作為災備時候，需要手動的在程式中修改金鑰。那麼，兩個Linked（在高階版的Redis中啟用異地災備）的Redis是否可以設定為相同的金鑰呢？因自建的Redis伺服器可以設定金鑰，那麼是否可以把Azure PaaS Redis和自建的Redis服務進行主從配置呢？

答案是：統統不可以。

 

 

參考資料

Azure Redis 快取中不支援 Redis 命令：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-configure#redis-commands-not-supported-in-azure-cache-for-redis

為高階 Azure Cache for Redis 例項配置異地複製：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-geo-replication

【Azure Redis 快取】由Azure Redis是否可以自定義密碼而引申出Azure PaaS的Redis服務是否可以和自建的Redis進行主從配置呢？

 

 

 

輔助連結快取如何進行故障轉移？

異地複製的快取不支援跨 Azure 區域的自動故障轉移。 在災難恢復方案中，客戶應該在其備份區域中以協調的方式啟動整個應用程式堆疊。 讓單個應用程式元件自行決定何時切換到其備份區域可能會給效能造成負面影響。 Redis 的主要優勢之一是，它是一個延遲極低的儲存。 如果客戶的主要應用程式與其快取位於不同的區域，則增大的往返時間可能會對效能產生顯著的影響。 因此，我們應該避免自動故障轉移，否則會造成暫時性的可用性問題。

若要啟動客戶發起的故障轉移，請先取消連結快取。 然後將 Redis 客戶端更改為使用（以前連結的）輔助快取的連線終結點。 取消連結兩個快取後，輔助快取將再次成為常規的讀取寫入快取，並直接從 Redis 客戶端接受請求。

 

 [完]

 
 

相關文章