Redisのslave-read-only設定の挙動

概要

Redisのレプリケーション設定にslave-read-only設定がある。
デフォルトはyesになっていてslaveにデータは書き込めないようになっている。
設定をnoにするとslaveにデータが書き込めるようになるがそのデータはそのslaveサーバーにしか存在しない状態になる。

その動きを確認した際のメモ。

検証した際のマスターとスレーブの構成は以下の通り

redis01	master
redis02	slave
redis03	slave

redis03(slave)

slave-read-only yesの状態

[tsunokawa@redis03 ~]$ redis-cli
127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
127.0.0.1:6379>
127.0.0.1:6379> set testkey6 testvalue6
(error) READONLY You can't write against a read only slave.
127.0.0.1:6379>

yesからnoに変更

slave-read-only yes

↓

slave-read-only no

これでredis03(slave)に書き込みができるようになった。

本当に書き込みができるか試してみる。

[tsunokawa@redis03 ~]$ redis-cli
127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
127.0.0.1:6379>
127.0.0.1:6379> set testkey6 testvalue6
OK
127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
 6) "testkey6"
127.0.0.1:6379>

書き込めた。

redis01(master)

[tsunokawa@redis01 ~]$ redis-cli
127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
127.0.0.1:6379>

redis02(slave)

[tsunokawa@redis02 ~]$ redis-cli
127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
127.0.0.1:6379>

当然redi01(master)ともう一つのスレーブサーバーのredis02(slave)には更新は反映されない。

先ほど無理やり書き込みを行ったredis03(slave)だけにsetした値
testkey6:testvalue6
同じキーで
testkey6:testvalue777
と値だけ変えたものをredis01(master)でsetした場合、redis03(slave)にだけ存在しているtestkey6:testvalue6はどうなるのか確認した。

結果を先に書くとデータが上書きされた。

redis03(slave)

[tsunokawa@redis03 ~]$ redis-cli
127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
 6) "testkey6"
127.0.0.1:6379> get testkey6
"testvalue6"
127.0.0.1:6379>

redis01(master)

[tsunokawa@redis01 ~]$ redis-cli
127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
127.0.0.1:6379>

testkey6はまだ無い

redis02(slave)

[tsunokawa@redis02 ~]$ redis-cli
127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
127.0.0.1:6379>

testkey6はまだ無い

この状態でredis01(master)から値をset

[tsunokawa@redis01 ~]$ redis-cli
127.0.0.1:6379> set testkey6 testvalue777
OK
127.0.0.1:6379> get testkey6
"testvalue777"
127.0.0.1:6379>

127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
 6) "testkey6"
127.0.0.1:6379>

レプリケーションされたため、redis02(slave)でも値が入った

[tsunokawa@redis02 ~]$ redis-cli
127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
 6) "testkey6"
127.0.0.1:6379> get testkey6
"testvalue777"
127.0.0.1:6379>

redis03(slave)は上書きされた。

[tsunokawa@redis03 ~]$ redis-cli
127.0.0.1:6379> KEYS *
 1) "testkey1"
 2) "testkey2"
 3) "testkey3"
 4) "testkey4"
 5) "testkey5"
 6) "testkey6"
127.0.0.1:6379>
127.0.0.1:6379> get testkey6
"testvalue777"
127.0.0.1:6379>

よって同じキーがsetされると上書きされる。
特にエラーが出たりはしない。

ブログ楽しいですよ

はじめに

この記事はwrite-blog-every-week Advent Calendar 2018 16日目の記事です。

私が常日頃ブログについて考えていることなどを書いてみたいと思います。

ブログを書くようになったきっかけ

ブログを書き始めたきっかけは技術的に困ってググったときに解説してあるブログを読んで何度も助けられてきたからです。
同じように自分が困ったり、ハマって解決したことをブログにすれば誰かの役にたつことがあるのではないかと思ったのが最初のきっかけでした。

ブログを書くようになってからの気づき

誰かの役に立てればと鼻息荒く始めたブログは書き始めてみると結構おもしろいもので様々な気づきがありました。

• ブログを書くのが純粋に楽しい
• メモを残す際にブログに書くかもと思うことである程度整ったメモを残すようになる
• そのメモが人に見られるのを意識して書くようになるのでドキュメントを書く練習になる
• ただメモするのではなく後から見返しても分かりやすいように書くので頭の整理になる
• そのままメモが所属先の会社のドキュメントになったり、チャットにペタっと貼り付けられるようになる
• 人様に見せるので間違いや補足情報がないかと再び見直しや調べ直しすることで自身の理解が深まる
• はてなブックマークのコメントやTwitterでフィードバックがもらえる
• Twitterのフォロワーが増えた
• 同僚から役に立ったと直接コメントをもらえる
• 力作のこれは読まれるだろうと思って投稿した記事はアクセスが伸びず、メモ程度に書いた記事なのにこんなに！？というくらいアクセス数が多い

ちなみに満を持して書いているこの技術ブログで一番アクセス数が多い記事は
俺的「うまい鰻屋 in 渋谷」ベスト3 - tsunokawaのはてなダイアリー
と渋谷のうなぎ屋さんのレビュー記事です。

ブログを書く上で心がけていること、気をつけていること

概要を書く

まず始めに概要を書くようにしています。
この概要にOSやソフトウェアのバージョンなど環境情報も書くようにしています。
出来れば結論も先に書いてこの記事を読んだ結果どんな情報が得られるかもわかるようにしています。

大文字小文字をしっかり確認

例えばGitHubであればGithubなどにならないよう正式名称を記載するようにしています。
これは利用サービスやソフトウェアに対する敬意としてドキュメントを参照して正式名称で書くように心がけています。

同じような意味の用語

例えば複数のネットワーク回線をまとめて多くの帯域を確保したり冗長構成を組む技術の名称として

• Bonding(ボンディング)
• Teaming(チーミング)
• LinkAggregate(リンクアグリゲーション)

といったものがあります。

利用環境によって用語の使い分けがされたり、厳密には意味が異なったりすると思うのですがどれもざっくりとしたくくりでは同じような意味です。(と個人的に思ってます)
現にLinuxのBondingについて記載した記事のアクセス解析結果を見ると上記3つのワードで検索してきてくださっている方がいます。

こういったワードはなるべくその記事内にあった用語を選んで書くようにしていますが、

Bonding(ボンディング)またはTeaming(チーミング)

というように記事内にはより多く検索に引っかかるように2つの用語を載せたりもしています。

どんな小さなことでも書く

ブログは長文を書かなければと思っていた時期が私にもありました。
が、今ではどんなに内容が小さく短いものでも書いていこうと思っています。
二番煎じだし…やこんな内容書いても…と思ったとしてもどんどん書いています。
それがどんな形で役に立つかわからないからです。
とはいえもっとブログ記事の幅を広げて内容が濃いものを書いていこうと思っています。

最後に

ブログはWeblogの略で当初は気になったWEBページのURLを貼って自分の思ったこと考えたことを書き添えるという
今でいうコメント機能付きのソーシャルブックマークの公開版のような存在だったように思います。
今では日記など様々な使われ方をしています。

そんな歴史を持っているブログですからどのような内容を書いても自由と考えこれからもどんどん書いていこうと思います。

もし書き始めようか迷ってる方は是非書いていきましょう。

ブログ楽しいですよ！

TerraformでGCSのライフサイクル設定

概要

GCPのGCS(ストレージ)でライフサイクルをTerraformで設定する例です。

例

バケット内のオブジェクトが365日経過後に自動削除されるよう設定しています。

resource "google_storage_bucket" "image-store" {
  name          = "image-store-bucket"
  location      = "asia-northeast1"

  lifecycle_rule {
    action {
      type = "Delete"
    }

    condition {
      age     = "365"
      is_live = "true"
    }
  }
}

参考

Google: google_storage_bucket - Terraform by HashiCorp