Amazon RDSによるレプリケーションについて理解する | DevelopersIO
Amazon RDSとは Amazon RDSは、AWSが提供するデータベースサービスです。別にEC2上にMySQLとかインストールすれば使わないんじゃない？って思う方もいらっしゃると思いますが、実はスゴいサービスなんです。何故サービスと名付けているか、それは、高可用性や耐障害性を実現しているからです。世の中の多くのシステムは、データベースが壊れるとシステム全体が止まってしまいます。ですから、データベースが止まらないように設計・運用する必要があります。 フォールトトレランスとは フォールトトレランスとは障害発生時にサービス全体を止めずにシステムを動かし続けることです。障害が起きないようにすることも大事ですが、障害が起こったときの対応も重要ですよね。Amazon RDSは、MultiAZ・リードレプリカによって障害に強いサービスを実現しています。 MultiAZ構成 RDSには起動時にMul
日々の覚書: pt-table-checksumでレプリケーション不整合を確認する
わたしはレプリケーション(と、バイナリーログ)フィルターが嫌いです。 フィルターが評価されるルール が理解されないまま運用されてカレントデータベースがNULLのままUPDATEを実行したりする人がいたりするので嫌なんですが、ストレージとかスレーブの性能とかネットワークの帯域とかで使わなければならないことも多々あります。 そんな時によく使う、 pt-table-checksum のメモ。 $ pt-table-checksum --socket /usr/mysql/5.6.17/data/mysql.sock --user root --password xxxx --tables d1.t1,d1.t2,d2.t1 --replicate test.pt-tcs --create-replicate-table TS ERRORS DIFFS ROWS CHUNKS SKIPPED TI
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
MySQL 5.6でスレーブをクラッシュセーフにするには | Yakst
MySQL Performance Blogの翻訳。MySQL 5.6の新機能である、リレーログのリカバリ機能を使って、クラッシュ誤にスレーブが自動復旧するように設定する方法。 September 13, 2013 By Stephane Combaudon スレーブがクラッシュした時にもリカバリ可能(クラッシュセーフ)に設定できるのは、MySQL 5.6のレプリケーション関連の大きな改善の一つだ。しかし、正しくこの機能を使うにはどう設定したらよいのか混乱してしまいがちなので、ここで手順をはっきりさせておこう。 概要 スレーブのMySQLを停止 relay_log_info_repository = TABLEとrelay_log_recovery = ONをmy.cnf追記 MySQLを再起動して待つ 細かな詳細 クラッシュセーフなスレーブを作りたい時に、なぜ上のような設定をしなければな
Redis Sentinelを運用してみたお話 | GMOメディア エンジニアブログ
こんにちは、宇津井です。 弊社ではゲソてんというゲームプラットフォームを運営しております。ゲソてんではサービスリリース当初から主にキャッシュ的な役割でRedisを導入していました。つい先日の事ですが訳あってRedis 2.6からサポートされたRedis Sentinelを採用しました。今回は、採用に至った経緯をご紹介します。 簡単なシステム構成 パフォーマンスは良いし、Memcachedには無い便利な機能を提供するRedisですが約一年間運用していくつかの問題が出てきました。 Redisサーバーが突然高負荷に陥るするとWebサーバーも高負荷に陥るRedisのReplicationは張ってるけどアプリケーション側でRedis Slaveへフェイルオーバーしない（MySQLを直接参照する）Redis落ちると恐らくMySQLサーバーが耐えられない（落ちた事無いけど）という事で対策を行ってきました
Redis 2.8 の Sentinel の動きを検証してみた - chrone's external storage
Redis 2.8 の redis-sentinel によるレプリケーションの自動フェイルオーバーについて、 比較的発生しそうな障害を想定して動作検証してみました。 結論から redis-server の自動再起動を構成している場合は要注意。 daemontools とか。 Master が落ちた後すぐ(例えば数秒)に再起動してきた場合、 再び Master としてレプリケーションに参加します。 よって、Master 再起動の前後でデータに差異があった場合でも、 再起動後のデータをもとに同期される為、データが破壊される可能性があります。 これを回避する為には、Sentinel により sdown/odown として認識されるのを待ってからインスタンスを復帰させるようにします。 復帰が早すぎると、障害(sdown/odown)ではなく再起動(reboot)と認識します。 レプリケーションの再
Redis:レプリケーション設定
Redis のレプリケーション設定についてメモ 公式ドキュメント http://redis.io/topics/replication Redis のレプリケーション マスターは複数のスレーブをもてる スレーブは別のスレーブの親になれる マスター/スレーブのレプリケート処理はノンブロッキング スレーブは writable (2.6 からは slave-read-only 設定が追加され、デフォルトは read-only) スレーブの用意 スレーブ用 redis サーバーを起動する。同じサーバ内に起動するのであれば、ポートを変更する必要がある。 redis.conf の port を修正すること。 スレーブ設定方法 confファイルでの設定 redis.conf にマスターの情報を記述する slaveof <masterip> <masterport> ex) slaveof 192.168
MySQL5.6のちょっとした話 - まめ畑
最近、とあるサービスの本番環境にMySQL5.6を導入していっています。社内だけの環境も含めて5システムに導入しました。 5.5からのアップデートや最初から5.6というものもあります。 今回、導入で変わった点いろいろありますが、メモ程度にまとめておきます。 間違いなどありましたら指摘していただけるとありがたいです。 Replicationエラー時 今までは、replicationのエラーが起こった場合は SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; とかでダメなクエリを確認しつつSKIP出来ればしていましたが、5.6でGTIDモードONの場合、これが使えなくなりました。 GTID便利なんですが、この点少し不便です。 以下のように直します。 まず、slaveでmaster server UUIDと最新のGTID、Retrieved_Gtid_Setを確認します
mysql replicationの復旧方法
Master_Log_File, Relay_Master_Log_Fileの意味は混同しやすいので、細心の注意を払ってください。また、それぞれのポジションの実態は、master.info, relay.infoというファイルです。 mysql レプリケーション 復旧シナリオ 事前準備 mysql レプリケーション 復旧シナリオ 事前準備 – mysqld_multi環境の構築 mysqld_multiを用いて、3つのmysqld(MySQLサーバ)を起動させます。動作確認のシナリオで使用する/etc/my.cnfの設定は以下の通りです。mysqld_multiの使い方は、mysqld_multiの設定方法を参照ください。 [mysqld] log-bin=mysql-bin relay-log=mysql-relay log-slave-updates master_info_repos
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
まだMySQL 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり（つまりクラッシュ）しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。（REDOやUNDOするアレのことだ。本稿では面倒臭い・・・ではなかった、本題ではないた
MySQL5.5で準同期レプリケーション構築 - IT Fragments
IT Fragments 情報技術系のトピックを扱う個人ブログです。プログラム制作物・システム考察・調べ物の備忘録・お勧めソフトウェア情報など MySQL5.5を用いた通常・準同期レプリケーション構築の解説です。レプリケーションとは何か、通常・準同期レプリケーションの対比、構築方法、必要な保守作業など。対象読者は多少MySQLサーバの設定を行ったことのある方を想定しています。 基礎知識 レプリケーションを構成する要素・どんな動作をするか・レプリケーションの種類。レプリケーション構築の前に知っておくべきことを解説します。 レプリケーションとは何か MySQLのレプリケーションはマスターサーバのデータを一つ以上のスレーブサーバに複製することでデータを冗長化する機能です。 レプリケーションを用いれば複数個所にデータベースの複製を設置できるので、荷分散と共に可用性・信頼性を向上させられます。設定は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Art of MySQL Replication.
GitHub - outbrain/orchestrator: MySQL replication topology manager/visualizer