MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
Facebookが何千台ものMySQLを人手を使わず自律管理する仕組み「MySQL Pool Scanner（MPS）」
おそらく世界でもっとも大規模にMySQLのクラスタを展開し、運用しているのがFacebookでしょう。複数のデータセンターにまたがり何千台ものMySQLサーバを運用するために、自動化の仕組みは欠かせません。 その自動化がどのような仕組みになっているのか。FacebookのデータベースエンジニアであるShlomo Priymak氏が、Under the hood: MySQL Pool Scanner (MPS)という記事をFacebookで公開しています。 かなり長い記事なので、ここではそのポイントをまとめて解説してみました。詳細はぜひ原文をあたってみてください。 MPSのおもな3つの機能 Facebookで稼働しているMySQLは、つねに1つのマスターとそこからレプリケーションされた複数のスレーブによるレプリカセットを構成しています。このレプリカセットの構造を維持し続けることで、可用性と
Triggerでpostgresqlからmongodbへのデータ同期案
こんにちわ、開発エンジニアのou.gです。 今回triggerでpostgresqlのデータをmongodbへの同期方法についてまとめました。 登場人物 PostgreSql Gearman Mongodb 処理流れ postgresqlの同期対象テーブルのレコードの変更があったら、triggerで検知して、 gearmanのclientがデータ変更情報をgearmanに送ります。 gearmanのworkerが変更データを拾って、加工（必要があれば）して、mongodbに反映します。 pggearmanについて postgresqlの中に使われるgearman clientはGearman PostgreSQL Functionsです。 最後のリリースは2009年で、9.1以降のpostgresqlには動けません。 postgresql9.1以降にも使えるpggearmanを作ってgit
MySQLでレプリケーションを構築する - かまたま日記3
社内勉強会でやったので、メモ。 こういうミドルウェアの設定ってやったこと無かったので、勉強になりました。 前提 同じサーバーで２つのMySQLデーモンを立ち上げる ポートはMaster:13301, Slave:13302 とする データは/data/mysql${port} にあるものとする MySQLのバージョンは5.5 今回はColdバックアップを行う ０．準備 データベース作成 mysql_install_db --datadir=/data/mysql13301datadirはデータとかテーブル定義とかを保存するディレクトリ バイナリログが出るようにMasterのmy.cnf(今回はmy-13301.cnfとした)を編集 以下の記述を有効にする。 ##### Binary Log Configuration log_bin = mysql-bin binlog_format =
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
