aws_volume_attachmentリソース実行後にEBSにファイルシステムを作りたい

俺です。

remote-execというprovisionerがあります。

このprovisionerはresource内で定義できるのでaws_ebs_volumeで作成したEBSをaws_volume_attachmentでターゲットのEC2へAttachした後に、

mkfsとmountでオラオラできます。

chefとかansibleとか面倒になって作りっぱなしで完結するならremote-exec最高。

以下定義例

• ebs.tf

resource "aws_ebs_volume" "prd-manage_volume-1a" {
  availability_zone = "${var.region}a"
  type = "${lookup(var.manage_extend_ebs_volume_type,"prd")}"
  size = "${lookup(var.manage_extend_ebs_volume_size,"prd")}"
  encrypted = "${lookup(var.manage_extend_ebs_volume_encrypted,"prd")}"
  count = "${lookup(var.manage_extend_ebs_count, "prd")}"
  tags {
    Name = "${lookup(var.manage_tag_Name, "prd")}"
  }
}

resource "aws_volume_attachment" "prd-manage_volume-1a" {
  device_name = "/dev/xvdh"
  volume_id = "${aws_ebs_volume.prd-manage_volume-1a.id}"
  instance_id = "${aws_instance.prd-manage-1a.id}"
  provisioner "remote-exec" {
    connection {
      type = "ssh"
      user = "ec2-user"
      key_file = "~/.ssh/id_rsa"
      host = "${aws_instance.prd-manage-1a.public_ip}"
    }
    inline = [
      "sudo mkfs -t ext4 /dev/xvdh",
      "sudo mkdir /mnt/data",
      "sudo mount /dev/xvdh /mnt/data"
    ]
  }
}

• console out

EBSが接続された後にmkfsが実行されています。

aws_volume_attachment.prd-manage_volume-1a (remote-exec):   Host: **.**.**.**
aws_volume_attachment.prd-manage_volume-1a (remote-exec):   User: ec2-user
aws_volume_attachment.prd-manage_volume-1a (remote-exec):   Password: false
aws_volume_attachment.prd-manage_volume-1a (remote-exec):   Private key: true
aws_volume_attachment.prd-manage_volume-1a (remote-exec):   SSH Agent: true
aws_volume_attachment.prd-manage_volume-1a (remote-exec): Connected!
aws_volume_attachment.prd-manage_volume-1a (remote-exec): mke2fs 1.42.12 (29-Aug-2014)aws_volume_attachment.prd-manage_volume-1a (remote-exec): Creating filesystem with 262
14400 4k blocks and 6553600 inodes
aws_volume_attachment.prd-manage_volume-1a (remote-exec): Filesystem UUID: 028ef97c-0d
79-4a8e-9ce6-c058c0f0d008
aws_volume_attachment.prd-manage_volume-1a (remote-exec): Superblock backups stored on
 blocks:
aws_volume_attachment.prd-manage_volume-1a (remote-exec):       32768, 98304, 163840,
229376, 294912, 819200, 884736, 1605632, 2654208,
aws_volume_attachment.prd-manage_volume-1a (remote-exec):       4096000, 7962624, 11239424, 20480000, 23887872
aws_volume_attachment.prd-manage_volume-1a (remote-exec): Allocating group tables: done
aws_volume_attachment.prd-manage_volume-1a (remote-exec): Writing inode tables: done  aws_volume_attachment.prd-manage_volume-1a (remote-exec): Creating journal (32768 blocks): done
aws_volume_attachment.prd-manage_volume-1a (remote-exec): Writing superblocks and file
system accounting information:
aws_volume_attachment.prd-manage_volume-1a (remote-exec): done

aws_volume_attachment.prd-manage_volume-1a: Creation complete

俺の記憶がすっとんでもなんとか思い出すためのterraform tips

俺です。

terraform 0.3.5の頃から2015/8現在0.6.2まで使い続けてきた中で得たtipsです。

思い出したら追記する はず 。

terraform 0.6.2は使わない

IAM Roleで認可された権限を認識しないバグがあり、IAM Roleを付与したEC2で動作しない。

ドハマりしたので絶対触らないのが吉之助。

8/11にリリースされたterraform 0.6.3か0.6.1を使いましょう。

Couchbase 3.0.1 cbbackupの話とcbbackupwrapper実行中のエラー Error with backup for running cbbackup

メムキャッシュだよぉーって言っておいて実は動いていたのはCouchbaseでした！

というのを夢見る俺ですこんばんは。moxiで負荷分散されてたのどんな気持ち？って聞いてみたい。

今回はCouchbaseのバックアップツールである cbbackup とwrapper tool cbbackupwrapper についての話です。

cbbackupのパッチ@Couchbase 3.0.1

Couchbase社の 河村さん に教えてもらったのですが

Couchbase 3.0/3.0.1のcbbackupには不具合があり, cbbackupwrapperに対してPatchが提供されています。 https://issues.couchbase.com/browse/MB-15345

このパッチを適用すると cbbackupwrapper に --sequential オプションが追加され, vBucketのバックアップ並列度を指定することができるようになります。

cbbackup/cbbackupwrapperを使っていて、 MB-15345 のパッチを適用してない方は是非適用しましょう。

自分はCouchbase Community Edition 3.0.1を使ってますが、

パッチを当てていないcbbackupで1レコード20KBのデータが1000万件あるCouchbaseサーバを

c4.xlargeのバックアップサーバにインストールしたcbbackupでバックアップしたところ、バックアップサーバのCPU使用率が100%になり無応答になる悲惨な状況を経験しました。

この問題を回避するため、重い腰を上げてパッチを当てようとしたところ、

そもそもCouchbase Server Community 3.0.1(RHEL)にはcbbackupwrapper/cbrestorewrapperがインストールされていなかったので、

Couchbase社が公開しているcouchbaes-cliのgithubリポジトリのCLIをcloneして使ってます。

https://github.com/couchbase/couchbase-cli

--sequential オプションの代わりに --parallelism と --number オプションが追加されています。

上記リポジトリをcloneして cbbackupwrapper を使ったところ、2000万件のデータをc4.2xlargeのバックアップサーバから約90分で取得できるようになりました。

cbbackupwrapperの引数を調整したらもう少し高速化できるかなーと考えてるところです。

これで解決かなーとと思いきや

Couchbase社のcouchbase-cliリポジトリにあるcbbackupwrapperを使ってたらある日からつらみが発生

あくまでも2000万件はテストで作ったデータなので、実データを cbbackupwrapper で吸い上げみたところ

Error with backup for running という見慣れぬエラーメッセージが出力されていました。

• コマンド

$ cd /usr/local/couchbase-cli
$ ./cbbackupwrapper -u **** -p **** http://192.168.0.11:8091 --path=/usr/local/couchbase-cli /mnt/cbbackup
Error with backup for running /usr/local/couchbase-cli/cbbackup -v -t 1 --vbucket-list=[900,901,902,903,904,905,906,907,908,909,910,911,912,913,914,915,916,917,918,9
19,920,921,922,923,924,925,926,927,928,929,930,931,932,933,934,935,936,937,938,939,940,941,942,943,944,945,946,947,948,949,950,951,952,953,954,955,956,957,958,959,960,961
,962,963,964,965,966,967,968,969,970,971,972,973,974,975,976,977,978,979,980,981,982,983,984,985,986,987,988,989,990,991,992,993,994,995,996,997,998,999] http://192.168.0.11:8091 /mnt/cbbackup/900-999 -u **** -p **** -m diff -b orenobucket 2>/mnt/cbbackup/logs/900-999.err
Error with backup for running /usr/local/couchbase-cli/cbbackup -v -t 1 --vbucket-list=[1000,1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1011,1012,1013,1014,10
15,1016,1017,1018,1019,1020,1021,1022,1023] http://192.168.0.11:8091 /mnt/cbbackup/1000-1023 -u **** -p **** -m diff -b orenobucket 2>/mnt/cbbackup/log/1000-1023.err
SUCCESSFULLY COMPLETED!
$ echo $?
0

• cbbackupwrapperが出力するログ

各vBucketのメッセージ数とバイト数を見る限り、バックアップは問題なく取得できていそうですが、pythonのtrace backがなんだろう。

bucket: orenobucket, msgs transferred...
       :                total |       last |    per sec
 batch :                 7950 |       7950 |       16.3
 byte  :           3123659280 | 3123659280 |  6400204.6
 msg   :               459774 |     459774 |      942.1
Traceback (most recent call last):
  File "/usr/local/couchbase-cli/cbbackup", line 12, in <module>
    pump_transfer.exit_handler(pump_transfer.Backup().main(sys.argv))
  File "/usr/local/couchbase-cli/pump_transfer.py", line 94, in main
    rv = pumpStation.run()
  File "/usr/local/couchbase-cli/pump.py", line 140, in run
    self.transfer_bucket_index(source_bucket, source_map, sink_map)
  File "/usr/local/couchbase-cli/pump.py", line 265, in transfer_bucket_index
    source_bucket, source_map)
  File "/usr/local/couchbase-cli/pump_dcp.py", line 92, in provide_index
    err, index_server = pump.filter_server(opts, source_spec, 'index')
  File "/usr/local/couchbase-cli/pump.py", line 1050, in filter_server
    if filtor in node["services"] and node["status"] == "healthy":
KeyError: 'services'

OSはAmazon Linux.システムのPythonは2.7.9

いきなり発生してつらあじ。

とりあえずcbrestorewrapperでリストアできるか試してみる・・・

Sensu 0.12にPagerDuty handlerを導入するまでの道のり

こんばんは俺です。最近SensuにPagerDuty handlerを導入して、PJに投下中です。

PagerDuty handlerは下記URLに記載されているとおりに導入できます。

Sensu Integration Guide - PagerDuty

ただ今回PagerDuty handlerを導入したsensu serverは0.12を使っており、

これが古すぎたためハマったので、手順を残しておきます。

ハマリポイントを産業以内で

1.sensu-pluginのバージョンを1.0以上にしてPagerDuty handlerを導入する

以上終わり。

詳細

sensu-pluginのバージョンアップ

• PagerDuty handlerはsensu-pluginが1.0以上でなければ動きませんのでsensu-plugin1.0以上をインストールします

$ /opt/sensu/embedded/bin/gem list sensu-plugin

*** LOCAL GEMS ***

sensu-plugin (0.2.2)
$ /opt/sensu/embedded/bin/gem install sensu-plugin
$ /opt/sensu/embedded/bin/gem list sensu-plugin

*** LOCAL GEMS ***

sensu-plugin (1.1.0, 0.2.2)

handler定義作成

• /etc/sensu/conf.d/handlersに任意の名称でPagerDutyをkickする定義を記述します。

OKもPagerDutyで制御するときは severities に含めましょう。

{
  "pagerduty": {
    "api_key": "**************************"
  },
  "handlers": {
    "hogehoge_pagerduty": {
      "type": "pipe",
      "command": "pagerduty.rb",
      "severities": [
        "warning",
        "critical",
        "unknown"
      ]
    }
  }
}

sensu-server/apiの再起動

再起動してハンドラを有効にします。

$ sudo service sensu-server restart
$ sudo service sensu-api restart

以上でsensu serverの設定は完了です。

client設定例(Chef LWRP)

Chef LWRPでSensuの監視定義を管理しているのであれば、以下の通り

sensu serverで設定したハンドラ名をattributeなりrecipesの handlers に記述します

• attributes/default.rb

default.sensu.default_handlers  = ["mail", "hogehoge_pagerduty"] 

• recipes/default.rb

sensu_check "check_resource_cpu" do
  command %{check-cpu.rb -w 80 -c 90}
  standalone true
  handlers node.sensu.default_handlers
  interval node.sensu.check_interval
  additional occurrences: node.sensu.check_occurrences
end 

以上です。

terraform <= 0.5.X で EC2のchange instance type

terraformと手動オペレーションでterraformを使ってlaunchしたEC2のインスタンスタイプを変更した時の話。

terraformにAWS EC2のinstance typeを変更するresourceはまだ提供されていません。(議論は issue#1270などで行われているみたいですが)

基本的にterminate -> launchの順です。

ステートレスなサーバであれば今のterraformが提供するforce new recreateで良いと思います。

ただDBサーバ等のステートフルなサーバのinstance typeを変更するときはちょっと困りモノです。

terraformで定義したresourceの状態はterraform.tfstate/terraform.tfstate.backupで状態保存してるので、手動オペレーションによる矛盾が発生したときはこのファイルを直接いじればOKです。

• instance typeを変更する該当インスタンスを停止
• instance typeを変更して起動
• terraformで定義したEC2のresourceにあるinstance typeを変更後のinstance typeに変更する
• terraform.tfstateをエディタで開いてinstance typeを変更したinstance idのinstance typeを変更後のinstance type名にする
• terraform planを実行して実行結果が下記のとおりであればOK(NGの場合は-/+ ~が出力されます)

No changes. Infrastructure is up-to-date. This means that Terraform
could not detect any differences between your configuration and
the real physical resources that exist. As a result, Terraform
doesn't need to do anything.

• terraform applyを実行して、下記のとおりであればOK

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

脳筋的変更対象の台数が増えるときっついかなー。

stop instance, modify系に期待。

terraform先生の今後の活躍にご期待ください。

出、出、出〜！xfs利用的resize2fs打奴〜〜〜ｗｗｗ

xfsファイルシステムにresize2fs叩いてm9(^Д^)ﾌﾟｷﾞｬｰされる俺です。

これな。 xfs_growfs

8.4. XFS ファイルシステムのサイズの拡大

HAProxyで実現するGalera Clusterノードのサービス脳筋的無停止メンテナンス

HAProxyのエンドポイントとなるGalera Clusterをメンテモードにすることで、 Galera Clusterへのアクセスを停止することができ、サービス無停止でのメンテナンスが実現できる。

利用例

• インスタンスタイプの変更
• メンテナンスイベントからの回避

※パッケージもローリングアップデートでできるかな

図

切替方法

• ロードバランサの状態確認

[root@ip-192-168-0 ~]# echo "show stat"|socat stdio /var/lib/haproxy/haproxy.socket
# pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max,check_status,check_code,check_duration,hrsp_1xx,hrsp_2xx,hrsp_3xx,hrsp_4xx,hrsp_5xx,hrsp_other,hanafail,req_rate,req_rate_max,req_tot,cli_abrt,srv_abrt,comp_in,comp_out,comp_byp,comp_rsp,lastsess,last_chk,last_agt,qtime,ctime,rtime,ttime,
admin_page,FRONTEND,,,0,0,40000,0,0,0,0,0,0,,,,,OPEN,,,,,,,,,1,2,0,,,,0,0,0,0,,,,0,0,0,0,0,0,,0,0,0,,,0,0,0,0,,,,,,,,
admin_page,BACKEND,0,0,0,0,4000,0,0,0,0,0,,0,0,0,0,UP,0,0,0,,0,313325,0,,1,2,0,,0,,1,0,,0,,,,0,0,0,0,0,0,,,,,0,0,0,0,0,0,-1,,,0,0,0,0,
haproxy-galera,FRONTEND,,,0,1,40000,1054,1409,4234,0,0,0,,,,,OPEN,,,,,,,,,1,3,0,,,,0,0,0,2,,,,,,,,,,,0,0,0,,,0,0,0,0,,,,,,,,
haproxy-galera,192.168.0.218,0,0,0,1,4000,348,461,1564,,0,,0,0,0,0,UP,100,1,0,1,1,310458,2867,128,1,3,1,,348,,2,0,,1,L7OK,200,8,,,,,,,0,,,,345,0,,,,,612,OK,,0,0,0,1,
haproxy-galera,192.168.0.219,0,0,0,1,4000,348,461,1276,,0,,0,0,0,0,UP,100,1,0,1,1,310406,2918,128,1,3,2,,348,,2,0,,1,L7OK,200,8,,,,,,,0,,,,345,0,,,,,12,OK,,0,0,0,1,
haproxy-galera,192.168.0.220,0,0,0,1,4000,348,487,1394,,0,,0,0,0,0,UP,100,1,0,1,1,310406,2917,128,1,3,3,,348,,2,0,,1,L7OK,200,8,,,,,,,0,,,,345,0,,,,,312,OK,,0,0,0,1,
haproxy-galera,BACKEND,0,0,0,1,4000,1054,1409,4234,0,0,,10,0,0,0,UP,300,3,0,,1,310458,2865,,1,3,0,,1044,,1,0,,2,,,,,,,,,,,,,,1035,0,0,0,0,0,12,,,0,0,0,1,

• メンテナンスモードに変更

[root@ip-192-168-0 ~]# echo "disable server haproxy-galera/192.168.0.218"|socat stdio /var/lib/haproxy/haproxy.socket

[root@ip-192-168-0 ~]# echo "show stat"|socat stdio /var/lib/haproxy/haproxy.socket
# pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max,check_status,check_code,check_duration,hrsp_1xx,hrsp_2xx,hrsp_3xx,hrsp_4xx,hrsp_5xx,hrsp_other,hanafail,req_rate,req_rate_max,req_tot,cli_abrt,srv_abrt,comp_in,comp_out,comp_byp,comp_rsp,lastsess,last_chk,last_agt,qtime,ctime,rtime,ttime,
admin_page,FRONTEND,,,0,0,40000,0,0,0,0,0,0,,,,,OPEN,,,,,,,,,1,2,0,,,,0,0,0,0,,,,0,0,0,0,0,0,,0,0,0,,,0,0,0,0,,,,,,,,
admin_page,BACKEND,0,0,0,0,4000,0,0,0,0,0,,0,0,0,0,UP,0,0,0,,0,313353,0,,1,2,0,,0,,1,0,,0,,,,0,0,0,0,0,0,,,,,0,0,0,0,0,0,-1,,,0,0,0,0,
haproxy-galera,FRONTEND,,,0,1,40000,1054,1409,4234,0,0,0,,,,,OPEN,,,,,,,,,1,3,0,,,,0,0,0,2,,,,,,,,,,,0,0,0,,,0,0,0,0,,,,,,,,
★haproxy-galera,192.168.0.218,0,0,0,1,4000,348,461,1564,,0,,0,0,0,0,MAINT,100,1,0,1,2,2,2869,128,1,3,1,,348,,2,0,,1,L7OK,200,8,,,,,,,0,,,,345,0,,,,,640,,,0,0,0,1,
haproxy-galera,192.168.0.219,0,0,0,1,4000,348,461,1276,,0,,0,0,0,0,UP,100,1,0,1,1,310434,2918,128,1,3,2,,348,,2,0,,1,L7OK,200,8,,,,,,,0,,,,345,0,,,,,40,OK,,0,0,0,1,
haproxy-galera,192.168.0.220,0,0,0,1,4000,348,487,1394,,0,,0,0,0,0,UP,100,1,0,1,1,310434,2917,128,1,3,3,,348,,2,0,,1,L7OK,200,8,,,,,,,0,,,,345,0,,,,,340,OK,,0,0,0,1,
haproxy-galera,BACKEND,0,0,0,1,4000,1054,1409,4234,0,0,,10,0,0,0,UP,200,2,0,,1,310486,2865,,1,3,0,,1044,,1,0,,2,,,,,,,,,,,,,,1035,0,0,0,0,0,40,,,0,0,0,1,

• メンテナンスモードの確認

メンテ状態になったGalera Clusterへアクセスが発生しない

[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.219 |
+--------------------+---------------+
[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.220 |
+--------------------+---------------+
[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.219 |
+--------------------+---------------+
[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.220 |
+--------------------+---------------+

• Galera Clusterのメンテナンス

HAProxyから外れたGalera Clusterを停止する。

Galera Clusterのインスタンスタイプを変更する

Galera Clusterを起動してメンバーノードとしてジョインさせる(MySQLを起動するとSSTにより自動でsyncされる)

• HAProxyのメンテナンスモード解除

[root@ip-192-168-0 ~]# echo "enable server haproxy-galera/192.168.0.218"|socat stdio /var/lib/haproxy/haproxy.socket
[root@ip-192-168-0 ~]# echo "show stat"|socat stdio /var/lib/haproxy/haproxy.socket
# pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max,check_status,check_code,check_duration,hrsp_1xx,hrsp_2xx,hrsp_3xx,hrsp_4xx,hrsp_5xx,hrsp_other,hanafail,req_rate,req_rate_max,req_tot,cli_abrt,srv_abrt,comp_in,comp_out,comp_byp,comp_rsp,lastsess,last_chk,last_agt,qtime,ctime,rtime,ttime,
admin_page,FRONTEND,,,0,0,40000,0,0,0,0,0,0,,,,,OPEN,,,,,,,,,1,2,0,,,,0,0,0,0,,,,0,0,0,0,0,0,,0,0,0,,,0,0,0,0,,,,,,,,
admin_page,BACKEND,0,0,0,0,4000,0,0,0,0,0,,0,0,0,0,UP,0,0,0,,0,313883,0,,1,2,0,,0,,1,0,,0,,,,0,0,0,0,0,0,,,,,0,0,0,0,0,0,-1,,,0,0,0,0,
haproxy-galera,FRONTEND,,,0,1,40000,1060,2299,12289,0,0,0,,,,,OPEN,,,,,,,,,1,3,0,,,,0,0,0,2,,,,,,,,,,,0,0,0,,,0,0,0,0,,,,,,,,
haproxy-galera,192.168.0.218,0,0,0,1,4000,348,461,1564,,0,,0,0,0,0,UP,7,1,0,1,2,4,3395,128,1,3,1,6,348,,2,0,,1,L7OK,200,8,,,,,,,0,,,,345,0,,,,,1170,OK,,0,0,0,1,
haproxy-galera,192.168.0.219,0,0,0,1,4000,351,1009,8451,,0,,0,0,0,0,UP,100,1,0,1,1,310964,2918,128,1,3,2,,351,,2,0,,1,L7OK,200,8,,,,,,,0,,,,345,0,,,,,135,OK,,0,0,0,38,
haproxy-galera,192.168.0.220,0,0,0,1,4000,351,829,2274,,0,,0,0,0,0,UP,100,1,0,1,1,310964,2917,128,1,3,3,,351,,2,0,,1,L7OK,200,8,,,,,,,0,,,,346,0,,,,,256,OK,,0,0,0,1,
haproxy-galera,BACKEND,0,0,0,1,4000,1060,2299,12289,0,0,,10,0,0,0,UP,207,3,0,,1,311016,2865,,1,3,0,,1050,,1,0,,2,,,,,,,,,,,,,,1036,0,0,0,0,0,135,,,0,0,0,38,

• HAProxyのロードバランス確認

[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.219 |
+--------------------+---------------+
[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.220 |
+--------------------+---------------+
[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.219 |
+--------------------+---------------+
[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.220 |
+--------------------+---------------+
[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.219 |
+--------------------+---------------+
[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.218 |
+--------------------+---------------+
[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.220 |
+--------------------+---------------+
[root@ip-192-168-0 ~]#  mysql -u root -p'<password>' -h 192.168.0.120 -P 33306 -e "show variables like 'wsrep_node_address'"
+--------------------+---------------+
| Variable_name      | Value         |
+--------------------+---------------+
| wsrep_node_address | 192.168.0.219 |
+--------------------+---------------+

以上です