Mackerelでは計画メンテナンスをどう実施しているか？ RedisをElastiCacheに移行した裏側をご紹介 - Hatena Developer Blog
こんにちは。MackerelチームSREのid:heleeenです。 Mackerelでは、2020年10月14日に計画メンテナンスを実施しました。今回は告知ブログに記載の通り、Mackerelが利用しているRedisをAmazon ElastiCache for Redis（以下、ElastiCache）へ移行しました。 本記事では、この10月の計画停止の裏側を紹介します。 どのようにElastiCacheへ移行するか 大半のRedisを無停止で移行 最後はElastiCacheへのオンライン移行を使用 メンテナンスに向けたさまざまな準備 メンテナンス手順書のチーム内レビュー メンテンス実施中の役割分担 なぜタイムキーパーが必要になったのか リモートで停止メンテナンスを実施する方法 検証環境を利用して事前にリハーサルも実施 Redisを安全に効率よく切り替えるために 参照するRedisを
JVM Operation Casual Talksに参加して思ったことをつらつらと書く - wyukawa's diary
JVM Operation Casual Talks : ATND 内容は参加者のブログエントリとtogetterが下記にありますのでそちらを見るとよいと思います。 JVM Operation Casual Talksに参加しました #jvmcasual - @johtaniの日記 2nd 「JVM Operation Casual Talks」発表資料のリンクをまとめてみる #jvmcasual - 元RX-7乗りの適当な日々 JVM Operation Casual Talks に参加してきました。 - susumuis Info JVM Operation Casual Talks #jvmcasual - Togetter で、このエントリでは発表を聞いて思ったことをつらつらと書きます。 ちなみに僕はJava歴10年以上なのですが、JVM運用経験はほとんどありません。最近はちょっと
Operations_JP - Cassandra Wiki
ハードウェア CassandraHardwareを参照して下さい。 チューニング PerformanceTuningを参照して下さい。 スキーマ管理 ノードのクロックをntpなどで同期して下さい。クロックが同期していない場合、更新時刻のずれによってスキーマ変更が無効と見なされる可能性があります。 LiveSchemaUpdatesを参照して下さい。[0.7で導入された機能] リング管理 それぞれのCassandraサーバ（ノード）には、そのホストを最初のレプリカ先として使用するキーを決定するためのトークンが割り当てられます。ノードのトークンでソートした場合、あるノードが担当するキー範囲は（前のノードのトークン、自ノードのトークン]です。即ち、「前の」トークン（その値は含まない）から自分のトークン（値を含む）までの間隔です。リングの中で最も小さいトークンを持つノードはそのトークン値以下のキー
クラウドは「障害が起こる」前提で使う
クラウドはそもそも、ユーザーのシステム運用負荷を下げられることがメリット。そのため、信頼性についてはある程度の割り切りが必要だ。それでも、クラウドの仕組みを知って、起こりうる障害に明示的に手を打てば、大きなトラブルを避けることができる。 これまで述べてきたように、クラウドの障害は「ストレージ障害」「仮想マシン障害」「データセンター設備障害」の三つに分類できる。利用者はこれらの障害が発生することを前提として、障害予防策を講じるべきだ。 例えば、ストレージ障害に備えて、データを定期的にバックアップする。仮想マシンの障害に備え、あらかじめ仮想マシンを複数台用意してクラスター構成にしておく。このような構成にしておけば、仮想マシンが異常終了した場合でも、別の仮想マシンに処理を引き継げる。データセンターの設備障害に備えるなら、異なるデータセンターにデータをバックアップしておく。 EC2は障害対策機能が
トラブルをわざと発生させサーバ問題解決能力を鍛える「Trouble-Maker」 - GIGAZINE
ほとんどのシステム管理者が経験したことがあるはずの状況は「何か悪いことが起きていて、サーバがダウンしているが、しかし何が起きているのか分からない」というシチュエーション。サーバを管理するシステムアドミニストレーターなどの立場でいると何が大変かというと、実際の製品として動かしている実環境でこのような問題が発生した場合です。 そこで役に立つのがこのオープンソースソフト「Trouble-Maker」です。 Trouble-Maker http://trouble-maker.sourceforge.net/ システム管理者の仕事を簡単にするため、多くのツールが存在していますが、未知の状況を経験している場合になんとかしてくれるわけではありません。この一連のソフトウェア群「Trouble-Maker」は既存の便利なツールとは異なり、問題を解決するのではなく、むしろ問題を引き起こします。インストールし
decommission、rebalance - kikumotoのメモ帳
decommission DataNode をクラスタから削除したい場合、前回書いたようにノードを停止してしまえば目的は果たせるけれど、停止により複製数が満たなくなるブロックができてしまい、自動複製されるまでにさらにノードが死んだりしたらデータ喪失になりかねない。 これを回避する目的で、decommission という仕組みがあるらしい。これは、複製を先に実行してからノードが停止される仕組みとなっている。 あるノードを decommission させるには、conf/hdfs-site.xml にあらかじめ dfs.hosts.exclude /path/to/exclude のように dfs.hosts.exclude パラメータに削除対象のノードを記述するファイルを指定しておく必要がある。そして、そのファイルには一行にひとつ、削除ノードの FQDN もしくは IP を記述する（必要あれ
ノードの追加・削除 - kikumotoのメモ帳
ノードの追加・削除といった Hadoop の運用面について少し調べてみたのでメモ。 ノードの追加 ノードを追加するにはだいたい以下のような手順となる。 Hadoop のソフトウェアをインストールする。 このとき、hadoop-env.sh や conf/*.xml も設定しておく。 NameNode、JobTracker ノードからパスワードなしで ssh ログインできるようにしておく。 NameNode, JobTracker の conf/slaves に追加したノードを追記する。 最後に、追加したノードで以下のコマンドを実行する。 $ cd $HADOOP_HOME $ ./bin/hadoop-daemon.sh start datanode $ ./bin/hadoop-daemon.sh start tasktracker これで、Hadoop クラスタにノードが追加され、HD
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
Cassandra for Sysadmins