開発メモ: スレーブエージェントによるKTからMySQL等へのレプリケーション
Kyoto TycoonからRDBMS等の他製品に対してレプリケーションを行う方法について述べる。 カスタマイズ機能群の最後のパーツ 以下のイラストのように、Kyoto Tycoonには、カスタマイズ性を高めるための様々な機能が実装されている。 HTTPの既存プロトコル上で任意のデータベース操作処理を実現するための「スクリプト言語拡張」。ユーザ定義の任意のプロトコルで任意のデータベース操作処理を実現するための「プラガブルサーバ」。既存のデータベース操作指示に対して任意の処理を行うための「プラガブルデータベース」。これら3つの機能を使えば、KTのほぼ全ての機能の振る舞いをユーザ定義のものに差し替えることができる。かなり究極的なカスタマイズ性を既に備えていると言える。 今回加わったのは、KTの外部の別システムとKTを連携させるための機能である。KTで更新ログを有効にすると、KTのデータベースに
開発メモ: memcachedプロトコルをKTにプラグインする
高効率キャッシュサーバ兼データベースサーバであるKyoto Tycoonのネットワーク通信機構をプラグインで切り替えられるようにして、memcachedプロトコルにも対応したというお話。 プラガブルサーバ Apacheは、様々なモジュールを後付けのプラグインで組み込むことで、非常に柔軟に機能追加を行えるようになっている。MySQLもストレージエンジンをプラグインで切り替えられるようになっていて、非常に柔軟なソリューションが提供できるようになっている。そのようなプラグインできるモジュールをプラガブルモジュールと呼ぶことにしよう。 同じように、KTでもストレージエンジン（DBM層）をプラガブルモジュールにする予定ではあるが、今回はストレージエンジンの話ではない。逆に、ネットワーク層をプラガブルモジュールにしてしまうのだ。そうすると、任意のプロトコルでデータベースを操作できるようになる。 DBM
開発メモ: HTTP記録機能付きプロクシによるレプリケーション
HTTPプロクシに更新ログを取らせれば、HTTPベースのいかなるサービスの内部状態もレプリケーションできるんじゃないのか？ という検討の過程を晒してみる。 背景 保守性の観点からKyoto Tycoon自体にはレプリケーション機能を持たせないことにしたが、実際のユースケースではレプリケーションが欲しくなることが多いこともわかっている。なので、外部機能によって何とかレプリケーションを実現したい今日この頃である。 KTにレプリケーションを実装しないもう一つの理由は、レプリケーションのための更新ログを記録するための処理がDBの更新処理よりも重いという本末転倒なことになっているからである。更新ログはレコードそのものに対して冗長なのでwriteの量も多いし、シーケンシャルアクセスなのでディスクには優しいが、データが際限なく増えるのでそれでも重い処理になる。また、DBはレコード単位の整合性だけを確保す
実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - （ひ）メモ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
Apache CouchDB
Data Where You Need It Apache CouchDB ™ lets you access your data where you need it. The Couch Replication Protocol is implemented in a variety of projects and products that span every imaginable computing environment from globally distributed server-clusters, over mobile phones to web browsers. Store your data safely, on your own servers, or with any leading cloud provider. Your web- and native a
最強のMySQL HA化手法 - Semi-Synchronous Replication
MySQL 6.0で搭載される予定の機能の一つに、Semi-Synchronous Replicationというものがある。コイツを使うととんでもなく凄いHA化ができるので、今日はその方法を紹介しよう。 まずはSemi-Synchronous Replicationの機能説明から。そもそもSemi-Synchrounousってナニ？どうして完全な同期でもなく非同期でもなくSemi-Synchronousなの？という疑問をまずは解消したいと思う。さっそく次の図を見て欲しい。 これはSemi-Synchronous Replicationの動作を図で表したものである。図だけではなんだかよく分からないと思うので、以下に各ステップの詳細を説明する。 アプリケーション（クライアント）からトランザクションをCOMMIT要求を出す。 バイナリログを更新する。 ストレージエンジン（テーブル）を更新する。
レプリケーションの遅延を計るシンプルな方法 - くるくるサーカス
MySQLでレプリケーションをするときに、必ず気になるのが master-slave間の遅延だと思います。 そこで、先日のDeNAさんのテクノロジーセミナーで開示していただいたネタをもとに簡単な遅延監視方法を実装してみました。 MySQLバージョン 5.1.23 binlog_format=MIXED まずmasterに以下のようなテーブルを作ります。databaseは適当に作ってください。 CREATE TABLE `replitimes` ( `No` int(10) unsigned NOT NULL AUTO_INCREMENT, `date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `ldate` timestamp NOT NULL DEFAULT '0000-00-00
repcached-2.0リリースのお知らせと、超簡単なサンプルコード : DSAS開発者の部屋
repcached-2.0(memcached-1.2.5ベース) をリリースしましたのでお知らせします。 http://lab.klab.org/modules/mediawiki/index.php/Repcached (日本語) http://repcached.lab.klab.org/ (英語) 今回の目玉はマルチマスタ構成のサポートです。 以前のバージョンはマスタ/スレーブ構成だったので、必ずマスタへ書き込まなければいけませんでした。そのため、接続先のサーバがマスタなのかどうかをクライアントが判別しなければいけなかったり、keepalivedなどと併用するなどの工夫が必要でしたが、今回のバージョンではその必要がなくなります。両方のサーバに対してデータを書き込むことができるようになったので、かなり使いやすくなったと感じています。 repcachedはパフォーマンスを最重視している
Repcached
repcachedについて repcachedとは、memcachedにデータのレプリケーション機能を追加実装したものです。 memcachedは、以下のようなところによく使われると思います。 一時的なデータの保存場所として キャッシュを保存する場所として RDBMSのデータのキャッシュ 生成したページデータのキャッシュ いずれの場合も消えていいデータなので、万が一memcachedがダウンしても問題はないはずです。 しかし、影響が全くないわけではありません。 例えば、MySQLのデータをmemcachedでキャッシュしている場合、memcachedがダウンしている間は直接MySQLにアクセスがいくことになりDBサーバの負荷が上がります。また、memcachedを再起動してキャッシュが失われた場合は、再びキャッシュが溜まるまではDBサーバに負荷がかかることになってしまいます。 このように
[ThinkIT] 第4回：CSVとBlackhole (3/3)
テーブルを作成する際、CREATE TABLE文のENGINE句に"BLACKHOLE"を指定することにより、Blackholeテーブルを作成することができます。Blackholeテーブルを作成すると、そのデータベースのディレクトリ内に、どのようなカラム構成にてできているかなどのテーブル構造のデータが格納された「テーブル名.frm」のみが作成されます。 次に示すは、「Blackhole_TEST」データベース内に「TEST00」という名前のBlackholeテーブルを作成した時のファイル一覧です。「Blackhole_TEST」ディレクトリ内に「TEST00.frm」ファイルのみが存在していることがわかると思います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.4.5 スケールアウトのためにレプリケーションを使用する