Linuxの運用・保守 - 高可用性Redisのキャッシュを構築します

序文

Redisのは、高性能のキーと値のデータベース、今より多くの企業やキャッシュサーバとしてのRedisを使用するアプリケーションです。家主は、JAVAのバックエンドプログラマで半分運用・保守エンジニアとみなすことができます。Redisのは、どのようにそれをすることはできません、Linuxサーバ上に構築されましたか？ここで、家主が構築するために、ゼロから連れて行ってくれました：Redisのスタンドアロンサーバー - > Redisのマスタースレーブのレプリケーション - >のRedis-センチネル高可用性を。そして、徐々に高可用性Redisのキャッシュサーバを構築します。

Redisのを設定します

1.ダウンロードして解凍します
最初の公式サイトからのRedis Redisのをダウンロードして解凍し、家主は、バージョン4.0.2を使用しています。ターンでは、次のコマンドを実行します。

cd /usr/local/
wget http://download.redis.io/releases/redis-4.0.2.tar.gz
tar -zxvf redis-4.0.2.tar.gz

そうでない場合はgccの依存関係、インストールの依存関係に対応

yum install -y gcc-c++ tcl

2.コンパイルとインストール
ダウンロードした後と解凍は、コンパイルするソースパッケージのインストール完了し、家主のRedisのインストールパスでは、/ usr / local / Redisので、学生は自分の文を変更することができます。PREFIXをインストールします=インストールしたいパス

cd /usr/local/redis-4.0.2/
make install PREFIX=/usr/local/redis

コピーRedisのは、あなたが直接これらのコマンドを実行できるように、完全なパスを書いていない、下に/ usr / sbinディレクトリに関連するコマンド

cd /usr/local/redis/bin/
sudo cp redis-cli  redis-server  redis-sentinel   /usr/sbin/

3.プロファイルのRedisを作成して

設定ディレクトリの/ etc /にインストール設定ファイルの後にコピーのRedis、redis.confはデフォルトで6379ポートRedisのプロファイル、Redisのソースディレクトリにredis.conf、です。

cp /usr/local/redis-4.0.2/redis.conf  /etc/

参照を解析する設定ファイルRedisの主なパラメータ

daemonize  no               #redis进程是否以守护进程的方式运行,yes为是,no为否(不以守护进程的方式运行会占用一个终端)
pidfile /var/run/redis.pid  #指定redis进程的PID文件存放位置
port 6379                   #redis进程的端口号
bind 127.0.0.1              #绑定的主机地址
timeout  300                #客户端闲置多长时间后关闭连接,默认此参数为0即关闭此功能
loglevel verbose            #redis日志级别,可用的级别有debug.verbose.notice.warning
logfile stdout              #log文件输出位置,如果进程以守护进程的方式运行,此处又将输出文件设置为stdout的话,就会将日志信息输出到/dev/null里面去了
databases 16                #设置数据库的数量,默认为0可以使用select <dbid>命令在连接上指定数据库id
save <seconds> <changes>    #指定在多少时间内刷新次数达到多少的时候会将数据同步到数据文件;
rdbcompression yes          #指定存储至本地数据库时是否压缩文件,默认为yes即启用存储;
dbfilename dump.db          #指定本地数据库文件名
dir ./                      #指定本地数据问就按存放位置;
slaveof <masterip> <masterport>     #指定当本机为slave服务时,设置master服务的IP地址及端口,在redis启动的时候他会自动跟master进行数据同步
masterauth <master-password>        #当master设置了密码保护时,slave服务连接master的密码;
requirepass footbared       #设置redis连接密码,如果配置了连接密码,客户端在连接redis是需要通过AUTH<password>命令提供密码,默认关闭
maxclients 128              #设置同一时间最大客户连接数,默认无限制;redis可以同时连接的客户端数为redis程序可以打开的最大文件描述符,如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
maxmemory<bytes>            #指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
appendonly no               #指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
appendfilename appendonly.aof       #指定跟新日志文件名默认为appendonly.aof
appendfsync everysec         #指定更新日志的条件,有三个可选参数no：表示等操作系统进行数据缓存同步到磁盘(快),always：表示每次更新操作后手动调用fsync()将数据写到磁盘(慢，安全), everysec：表示每秒同步一次(折衷，默认值);

3.1開始するには、バックエンドの設定：
デフォルトのRedisはあなたが終了してCtrl + Cを使用している場合、それが終了Redisのもお勧めできません、その後、現在のウィンドウ内に維持されなければならない、開始するためのフロントエンドです。

vi /etc/redis.conf
Redisの設定ファイルはいいいえデーモン化、新たな価値のデーモン化に古い値を変更しないように

3.2アクセスの設定：
Redisのデフォルトは、マシンへのアクセスを可能にしますが、時には我々はRedisのがリモートでアクセスすることが必要です。

vi /etc/redis.conf

ライン構成をバインドして下さい、デフォルトは次のとおりです。＃バインド127.0.0.1

＃コメントを削除し、読み：この設定は有効になりますバインド0.0.0.0は、すべてのリモートアクセスを可能にします。あなたがアクセスを制限するために割り当てたい場合は、対応するIPを設定することができます。

Redisの3.3設定変更ログ：
デフォルトは、ラインのログファイルの設定を見つける：「ログファイル」、ログファイル/var/log/redis_6379.logを変更

3.4 Redisの要求のパスワードを設定します：
vi /etc/redis.conf

＃requirepass foobared：デフォルトでは、この行のコメントを見つけることです

requirepass「123456」：コメントのない、あなたが設定したいパスワードを変更foobared、例えば、私はするつもり：123456ので、私はに変更しました

下に再起動するようにサービスを変更した後

あなたのパスワードを持っていたら、クライアントを入力しますので、あなたが訪問する必要があります：Redisの-CLI -h 127.0.0.1 -p 6379 -a 123456

4. Redisの一般的な操作

4.1開始

/usr/local/redis/bin/redis-server /etc/redis.conf

4.2閉じます

/usr/local/redis/bin/redis-cli -h 127.0.0.1 -p 6379 shutdown

4.3アクティブにするかどうかをチェックします

ps -ef | grep redis

4.4クライアントが入力します

redis-cli

閉じるクライアント4.5

redis-cli shutdown

起動時に4.6構成の設定

echo "/usr/local/redis/bin/redis-server /etc/redis.conf" >> /etc/rc.local

4.7オープンファイアウォールのポートは、
ルールを追加します：iptablesの-I INPUT -pのtcp -mのTCP 6379 --dportはACCEPT -j
ルールを保存：サービスiptablesの保存
、再起動iptablesの：サービスのiptablesを再起動します

システムサービスとして登録5. Redisの

/etc/init.dディレクトリにRedisのサービスを追加するためのスクリプトを、開始、一時停止して再起動します：

我々/etc/init.d/redis

次のようにスクリプトを読み取ります。

#!/bin/sh  
#  
# redis - this script starts and stops the redis-server daemon  
#  
# chkconfig:   - 85 15  
# description:  Redis is a persistent key-value database  
# processname: redis-server  
# config:      /usr/local/redis/bin/redis-server
# config:      /etc/redis.conf  
# Source function library.  
. /etc/rc.d/init.d/functions  
# Source networking configuration.  
. /etc/sysconfig/network  
# Check that networking is up.  
[ "$NETWORKING" = "no" ] && exit 0  
redis="/usr/local/redis/bin/redis-server" 
prog=$(basename $redis)  
REDIS_CONF_FILE="/etc/redis.conf" 
[ -f /etc/sysconfig/redis ] && . /etc/sysconfig/redis  
lockfile=/var/lock/subsys/redis  
start() {  
    [ -x $redis ] || exit 5  
    [ -f $REDIS_CONF_FILE ] || exit 6  
    echo -n $"Starting $prog: "  
    daemon $redis $REDIS_CONF_FILE  
    retval=$?  
    echo  
    [ $retval -eq 0 ] && touch $lockfile  
    return $retval  
}  
stop() {  
    echo -n $"Stopping $prog: "  
    killproc $prog -QUIT  
    retval=$?  
    echo  
    [ $retval -eq 0 ] && rm -f $lockfile  
    return $retval  
}  
restart() {  
    stop  
    start  
}  
reload() {  
    echo -n $"Reloading $prog: "  
    killproc $redis -HUP  
    RETVAL=$?  
    echo  
}  
force_reload() {  
    restart  
}  
rh_status() {  
    status $prog  
}  
rh_status_q() {  
    rh_status >/dev/null 2>&1  
}  
case "$1" in  
    start)  
        rh_status_q && exit 0  
        $1  
        ;;  
    stop)  
        rh_status_q || exit 0  
        $1  
        ;;  
    restart|configtest)  
        $1  
        ;;  
    reload)  
        rh_status_q || exit 7  
        $1  
        ;;  
    force-reload)  
        force_reload  
        ;;  
    status)  
        rh_status  
        ;;  
    condrestart|try-restart)  
        rh_status_q || exit 0  
    ;;  
    *)  
        echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart| reload|orce-reload}"  
        exit 2  
esac

スクリプトに与えられた権限

chmod 755 /etc/init.d/redis

停止して再起動し、起動します。

service redis start
service redis stop
service redis restart

これまでのところ、Redisのスタンドアロンサーバが設定されているが完了している、のは、マスタ・スレーブ・アーキテクチャを構築する方法を見てみましょう。

Redisのマスタースレーブアーキテクチャ建物

1. Redisのサーバーの説明

172.16.2.185:6379 主

172.16.2.181:6379 从

2. Redisのマスタ-スレーブ・アーキテクチャの構成

• Redisの210行（おそらく）を見つけ、マシンから設定ファイルを編集し、この行は、デフォルトのコメントのようになります。＃slaveof <MASTERIP> <masterport>
• ホストは、パスワードを設定している場合、あなたはまたmasterauth <マスターパスワード>この行、コメントを削除し、代わりにmasterauthホストを見つける必要があり、slaveof 172.16.2.185 6379：私たちは、次のようなコメントを削除し、私たち自身のIPを記入し、ホストのポートする必要がありますパスワード。
• 設定後、Redisのサービスからマシンを再起動
• 再起動が完了した後、ホストのRedis-cliの状態でのRedisは-CLI入力-h 127.0.0.1 -p 6379 -a 123456、次のように入力しますINFO複製からホストマシンに接続された、どのような役割で、現在のRedisのホストを照会することができます。

情報をホスト172.16.2.185

# Replication
role:master
connected_slaves:1
slave0:ip=172.16.2.181,port=6379,state=online,offset=28,lag=1
master_replid:625ae9f362643da5337835beaeabfdca426198c7
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:28
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:28

スレーブ情報172.16.2.181

# Replication
role:slave
master_host:172.16.2.185
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:210
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:625ae9f362643da5337835beaeabfdca426198c7
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:210
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:210

• 私たちは、ホストのRedisの-cliの状態を入力し、その値を設定し、など：この時点では、マスタ・スレーブ構成では、我々のテストを完了した設定myblog YouMeek.com
• myblogを取得し、我々は値を得ることができることを見つけることができます。この時点で、：私たちは、ただそこにあるかどうかを確認するために一連の値を取得し、マシンからの状態のRedis-CLIに切り替えます。

3. Redisのマスタ - スレーブ・アーキテクチャの概要

• ライブラリーからのデータを書き込む機能を持っていない、またはエラーになりますので注意してください。ライブラリから読み取り専用の能力を。
• マスタ - スレーブ・アーキテクチャの利点：プライマリ・データベース接続の圧力を低下させる、メインライブラリの機能をオフにすることができることに加えて、処理対象のライブラリから永続的な機能を持続しました。
• ライブラリーからの最初の構成情報が主リザーバに接続され、ライブラリからの第二の接続設定情報がライブラリから最初の後ろに接続され、ライブラリからの第三のケースが存在する場合、我々は、三分の一を置くことができそうであっても上の第二のライブラリー、およびからライブラリから構成情報。

Redisのセンチネル高可用性アーキテクチャ建物

1.自動フェイルオーバー

• プライマリバックアップがファブリック構成のRedisから作られますが、それは完璧に見えます。Redisのからぶら下がっメインのRedisは書き込みのみサービスを提供することはできません読み込みサービスを提供することができたときにでも、Redisのため現在は、マスター・スレーブレプリケーションのバックアップを（マスター・マスター・レプリケーションがサポートされていません）をサポートしています。メインのRedisはRedisのは、メインのRedisになってからアップグレードしてみましょう、ハングアップする場合だから、私は、道を見つけなければなりませんでした。

• これは、メインのRedisは、サービスを提供できない場合、RedisのセンチネルはRedisのRedisのベースからアップグレードすることができ、そしてRedisをから他の構成可能な、彼らは新しいプライマリRedisのを使ってみましょう、この機能を自動フェイルオーバー、Redisのセンチネルが必要ですレプリケーションバックアップ。

注意：以下のユースケースの2つだけのサーバー、少なくとも3つの構造のRedis Sentinelのサーバを推奨しますが、家主怠け者。

RedisのSentinelは、以下の機能を提供します。

1. 監視：センチネル常にマスターとスレーブ正常動作するかどうかを確認してください。
2. 通知：問題のモニタリングステーションのRedisのインスタンスは、あなたがAPIや他のアプリケーションを介してシステム管理者に通知することができます。
3. 自動フェイルオーバー：マスターが正常に実行されていない場合は、センチネルは、フェイルオーバー・プロセスを開始することができ、マスターになるためにアップグレード奴隷になり、他のスレーブを新しいマスターを使用するように再設定、およびアプリケーションが新しいアドレスRedisのサーバー通知を使用しています。
4. 構成プロバイダ：センチネルのRedisたクライアントの信頼できるソースとして：信頼性の高い現在のマスターのアドレスにセンチネルクライアント接続要求。障害が発生した場合は、Sentinelは、新しいアドレスと報告しています。

デフォルトでは、各センチネル節は、第PINGコマンドRedisのセンチネルノードと他のノードごとに一度の頻度を送信し、ノードがオンラインノードを返信するか否かを判定する。
ダウン後millisecondes MSは、有効な応答が受信されない場合、ノードはオフラインで主観的に決定されます。

ノードがマスタである場合、ノードは他のセンチネルノードにあるマスタダウン・バイ・ADDRコマンドセンチネルセンチネルによって求められますノード<クォーラム>マスタ数は、決意が到達可能でない超えた場合、そのノードを決定しますマスターは、センチネルノードが目的オフラインすることを決定します。

今回は、Sentinelは、それぞれが有力センチネルが運営マスターノードのフェイルオーバーに、リーダーセンチネルを選出協議します。

以下の3つの操作を含んでフェイルオーバー：

1. すべてのスレーブサーバでは、スレーブを選ぶ、とマスターに変換します。
2. 他のスレーブサーバが代わりに新しいマスターをコピーしてみましょう。
3. 新しいスレーブマスターに古いマスター、バックオンライン古いマスター、それは新しいマスターの奴隷になりますときにそう。

2. Redisのセンチネル高可用性アーキテクチャを設定し

、ここで2台のサーバー、各サーバー上のRedisのサーバーとのRedis・センチネルサービスを開きます。

Redisのサーバーの説明

172.16.2.185:6379 主

172.16.2.181:6379 从

Redisの-センチネル説明

172.16.2.185:26379

172.16.2.181:26379

2.1 Redisのコンフィギュレーションファイルの確立

失敗は自動的すなわちslaveof、自動的にmasterauth書き込みません、主従関係を書き換えますので、自動フェイルオーバーを行う場合は、すべてのredis.confはmasterauthに設定されていることをお勧めします。Redisのパスワードを設定していなかった場合は、無視することができます。

プログラム上のRedisのは、インストールされている、我々は、構成のRedis-センチネルは、システム設定ディレクトリは/ etcに/ダウンのRedis-センチネルコンフィギュレーションファイルをコピーします増やす必要があり、sentinel.confはRedisの-センチネルプロファイルであり、センチネルRedisのソースディレクトリ内の.conf。

cp /usr/local/redis-4.0.2/sentinel.conf  /etc/

次のように設定ファイルを変更Sentinel.conf：

vi /etc/sentinel.conf

protected-mode no
sentinel monitor mymaster 172.16.2.185 6379 2
# redis在搭建时设置了密码，所以要进行密码配置
sentinel auth-pass mymaster “123456“
#5秒内mymaster没有响应，就认为SDOWN
sentinel down-after-milliseconds mymaster 5000  
sentinel failover-timeout  mymaster 15000

最終的な構成に加え、

logfile /var/log/sentinel.log
pidfile  /var/run/sentinel.pid
daemonize yes

プロフィールの説明：

1.port：現在のポートを実行しているセンチネルサービス

2.dir：ランタイムの一時ファイルはセンチネルサービスをフォルダ

master001 192.168.110.10163792を監視3.sentinel：Sentinelはmaster001というプライマリRedisのインスタンスを監視するために、一次例のIPアドレスは、ホストアドレス192.168.110.101、ポート番号6379であり、プライマリ・インスタンスの故障は、少なくともていると判断されますSentinelは、非準拠センチネルの合意数限り、自動フェイルオーバーが実行されません、二つのプロセスに合意しました

必要なRedisのインスタンスの有効期限が切れたミリ秒数を指定センチネル：4.sentinelダウン後のミリ秒は30000をmaster001。今回の例はPINGが戻ってきたときを超え、直接エラーを返し、その後、この例Sentinelは、主観的にオフラインにマークされていません。一つだけセンチネル・プロセスは、必ずしも自動フェールオーバーインスタンスにつながらない主観的なオフラインのマーク：センチネル十分な数の主観的なオフラインのインスタンスとしてマークされた後にのみ、インスタンスは、組立ラインオフ目的としてマークされないであろう自動フェイルオーバーが実行される時期

フェイルオーバーを実行するときに、よりRedisの例の場合に小さく、この番号から、インスタンスのRedis新しい同期マスタインスタンスの最大数から、指定された、時間同期：5.sentinelパラレル同期は1 master001フェイルオーバーを完了するのに必要な時間の長さ、長いです

6.sentinelフェイルオーバー・タイムアウトmaster001 180000：その時間（ミリ秒）の間、フェイルオーバー操作を完了する障害、障害フェイルオーバーであると考えられます

7.sentinel通知スクリプト：スクリプトは、警察を呼び出し、異常監視ポイントの検出されたセンチネルインスタンスRedisの例を指定します。オプションの設定項目が、非常に一般的な

2.2オープンファイアウォールポート

添加规则：iptables -I INPUT -p tcp -m tcp --dport 26379 -j ACCEPT
保存规则：service iptables save
重启 iptables：service iptables restart

2.3。出発のRedis、センチネル

redis-sentinel  /etc/sentinel.conf

Renyiyitaiマシンは、関連するサービスの情報を表示することができます

redis-cli -h 127.0.0.1 -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=mymaster,status=ok,address=172.16.2.185:6379,slaves=1,sentinels=2

3.テスト自動フェイルオーバー

3.1は、主Redisのを停止します

redis-cli -h 172.16.2.185 -p 6379 -a 123456 shutdown

3.2ビューのRedis-センチネルの状態を監視

# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=172.16.2.181:6379,slaves=1,sentinels=2

主なライブラリーを強化するために、ライブラリから発見。

3.3留意事項

• マスターをオフにした後、センチネルはSDOWNの十分な数を表示する場合は、odownか試す - フェイルオーバーは、設定が正しいパスワードなどで確認していません
• マスターを停止した場合、切り替えるようにしようと、私はログが解決された状況の2種類に分けられ、フェイルオーバー・アボート-に選出されていない表示されますが見つかりました：

Redisのインスタンスが設定されていない場合

protected-mode yes
bind 172.16.2.185

センチネル・コンフィギュレーション・ファイルではプロテクトモードなしを追加します

Redisのインスタンスがそこに構成されている場合

protected-mode yes
bind 172.16.2.185

次に、設定ファイルセンチネルを追加

protected-mode yes
bind 172.16.2.185

この時点で、Redisの高可用性プログラムが完成した構造となっています。

VIP仮想IPは、外部の高可用性を提供します

従来例1.概要は、
IPとポートを必要ですが、Redisのサーバーのフェイルオーバークライアントプログラムは、（例えば、JAVAプログラム）Redisの接続、メインのRedisを変化させ、IPアドレスも変更されます。どのようにクライアントがRedisのマスターの現在のプログラムのIPアドレスとポートを感じるのですか？Redisの-センチネルセンチネルのいずれかを要求するためのインタフェースを提供し、送信センチネル取得マスター-ADDR-によって -name <マスター名> Redisの主電流IPとポートを得ることができます。

各クライアント接続Redisの前に、Xianxiangセンチネルは、メインRedisのIPとポートを取得するための要求を送信し、リターンRedisのIPとポートに接続されています。

この方法の欠点は、各操作は、少なくとも2つの接続要求、センチネル最初の要求、第2の要求のRedisを送信する必要があり、Redisのは明らかです。

より良いアプローチは、当然のことながら、このようなRedisのような環境を構成するための特定の要件は、VIPをサポートしていないことが、アリのクラウドサーバー上に構築しているVIPを使用することです。

Redisのフェイルオーバーは、あなたがする必要があるときVIPスキーム、外国のRedisのシステムは、常に同じIPアドレスで新しいマスターになりましたRedisのサーバーに以前のVIP Redisのサーバーからシフトさせることです。

例：現在のシステムのメインのRedis RedisのIPアドレスが172.16.2.185であるには、VIP（172.16.2.250）がVIP（172.16.2.250）と172.16.2.185、クライアントアドレスRedisの接続を指して、それが実際には現在のプライマリのRedisに接続されています、これセンチネルに送信要求を回避することができます。

クライアントが任意のコードを変更する必要がないように、ダウンメインのRedis、主にこのサーバーのフェイルオーバー、Redisの172.16.2.181は、その後、VIP（172.16.2.250）172.16.2.181ポイント、172.16に接続されている場合.2.181このメインのRedis。

2.ドリフトVIPはRedisのフェイルオーバーを実現

質問は、フェイルオーバー時のRedisのは、VIPが新しいマスターRedisのサーバーにドリフトするか、である今では。

ここRedisのセンチネルパラメータクライアント再構成スクリプトを使用することができる、このパラメータは、スクリプトを実行するように構成され、センチネル行うフェイルオーバー時間は、スクリプトを実行し、6つのパラメータ<マスター名>、<役割>、<状態>を渡されます<から-IP>、<からポート>、<に-IP>、<へのポート>、<へ-IP>新しいマスターのRedisのIPアドレスである場合には、このスクリプトではVIPドリフトのない動作を行うことができます。

sentinel client-reconfig-script mymaster /opt/notify_mymaster.sh

二つのサーバにRedisの-センチネルプロファイル/etc/sentinel.confを変更し、一番上の行を増やします。次のようには/ opt /ディレクトリnotify_mymaster.shスクリプトファイルの下に作成され、スクリプトは、VIPドリフトのない操作を行います。

vi /opt/notify_mymaster.sh

#!/bin/bash
echo "File Name: $0"
echo "Quoted Values: $@"
echo "Quoted Values: $*"
echo "Total Number of Parameters : $#"

MASTER_IP=${6}  #第六个参数是新主redis的ip地址
LOCAL_IP='172.16.2.185'  #当前服务器IP，主机172.16.2.185，从机172.16.2.181
VIP='172.16.2.250'
NETMASK='24'
INTERFACE='eth1'
if [ ${MASTER_IP} = ${LOCAL_IP} ]; then
     sudo /sbin/ip addr add ${VIP}/${NETMASK} dev ${INTERFACE}  #将VIP绑定到该服务器上
     sudo /sbin/arping -q -c 3 -A ${VIP} -I ${INTERFACE}
    exit 0
else
     sudo /sbin/ip addr del ${VIP}/${NETMASK} dev ${INTERFACE}   #将VIP从该服务器上删除
   exit 0
fi
exit 1  #如果返回1，sentinel会一直执行这个脚本

スクリプトに与えられた権限

chmod 755 /opt/notify_mymaster.sh

Redisのは、現在のマスター172.16.2.185で、手動でサーバー上のVIPにバインドする必要があります。

/sbin/ip  addr add 172.16.2.250/24 dev eth1
/sbin/arping -q   -c 3 -A 172.16.2.250 -I eth1

VIPのみがこれらのマシンの一つだけをバインドするので、redis.confに追加0.0.0.0をバインドするために変更することが提案されています

vi /etc/redis.conf

設定バインド0.0.0.0

VIPのみがこれらのマシンの一つだけをバインドするので、sentinel.confに追加0.0.0.0をバインドするために変更することが提案されています

vi /etc/sentinel.conf

設定バインド0.0.0.0

再起動のRedis

service redis restart`

再起動センティネル

redis-sentinel /etc/sentinel.conf

彼は、ホストへのVIPアクセスを通じて、別のマシン172.16.2.181上で私たちに従っ

redis-cli -h 172.16.2.250 -p 6379 -a 123456 INFO replication

次のような情報があり、正常に通信することができます：

# Replication
role:master
connected_slaves:1
slave0:ip=172.16.2.181,port=6379,state=online,offset=0,lag=0
master_replid:325b0bccab611d329d9c2cd2c35a1fe3c01ae196
master_replid2:c1f7a7d17d2c35575a34b00eb10c8abf32df2243
master_repl_offset:22246293
second_repl_offset:22241024
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:22237293
repl_backlog_histlen:9001

アクセスホストセンチネル

redis-cli -h 172.16.2.250 -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=mymaster,status=ok,address=172.16.2.185:6379,slaves=1,sentinels=3

別のサーバーへのVIPドリフトかどうかを確認するためにRedisのサービスのホストオフ以下。

redis-cli -h 172.16.2.185 -p 6379 -a 123456 shutdown

スイッチかどうかをチェックします

redis-cli -h 172.16.2.250 -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=mymaster,status=ok,address=172.16.2.181:6379,slaves=1,sentinels=3

Sentinelは、マスタに昇格スレーブ172.16.2.181を照会することによって発見しました。

VIPのアクセスによるRedisの接続

redis-cli -h 172.16.2.250 -p 6379 -a 123456 INFO replication

# Replication
role:master
connected_slaves:0
master_replid:cab30a4083f35652053ffcd099d70b9aaf7a80f3
master_replid2:3da856dd33cce4bedd54926df6797b410f1ab9e8
master_repl_offset:74657
second_repl_offset:36065
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:74657

上記の情報番組からは、VIPドリフトは成功しています。おめでとう、幸運、鶏の夜。

概要

これまでのところ、高可用性Redisのキャッシングサービスが終了し設定されている、その後、少し後の記事は、どのようにJAVAのRedisを通じて関連する操作を接続する方法をお教えします。このようして、ビルドした後、一緒に共有すること自由としてRedisのクラスタのクラスタリング・ソリューションとして。