開発メモ: HTTP記録機能付きプロクシによるレプリケーション
HTTPプロクシに更新ログを取らせれば、HTTPベースのいかなるサービスの内部状態もレプリケーションできるんじゃないのか？ という検討の過程を晒してみる。 背景 保守性の観点からKyoto Tycoon自体にはレプリケーション機能を持たせないことにしたが、実際のユースケースではレプリケーションが欲しくなることが多いこともわかっている。なので、外部機能によって何とかレプリケーションを実現したい今日この頃である。 KTにレプリケーションを実装しないもう一つの理由は、レプリケーションのための更新ログを記録するための処理がDBの更新処理よりも重いという本末転倒なことになっているからである。更新ログはレコードそのものに対して冗長なのでwriteの量も多いし、シーケンシャルアクセスなのでディスクには優しいが、データが際限なく増えるのでそれでも重い処理になる。また、DBはレコード単位の整合性だけを確保す
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.4.4 異なるソースおよびレプリカのストレージエンジンでのレプリケーションの使用
レプリケーションプロセスでは、ソース上の元のテーブルとレプリカ上のレプリケートされたテーブルが異なるストレージエンジンタイプを使用するかどうかは関係ありません。 実際、default_storage_engine システム変数はレプリケートされません。 これは、異なるレプリケーションシナリオに異なるエンジンタイプを利用できるという点で、レプリケーションプロセスにいくつかの利点を提供します。 たとえば、典型的なスケールアウトシナリオ (セクション17.4.5「スケールアウトのためにレプリケーションを使用する」 を参照) では、トランザクション機能を利用するためにソースで InnoDB テーブルを使用しますが、データの読取りのみであるためトランザクションサポートが不要なレプリカでは MyISAM を使用します。 データロギング環境でレプリケーションを使用する場合は、レプリカで Archive
MySQL レプリケーションの設定 - とみぞーノート
1.2 レプリケーションの動作レプリケーションでは最初にDBの内容を同期させた後、Masterサーバーで実行された更新系のクエリ(UPDATEとか)をSlaveに渡してSlaveでも同じクエリを実行していくことで、DBを同期させている(図1)。 Master側で実行された更新系クエリはバイナリログに蓄えられており、Slave側が接続してきたら、前回の接続からの変更分をSlave側に送信する。Slave側は受け取ったクエリを一旦リレーログに蓄えて順次クエリを実行してDBを同期させていく。リプリケーション動作にはBinlogDump,I/O,SQLの3つのスレッドが連携して動作する。 2.設定手順 (Master-Slave構成) 2.1 Master側の設定の確認Master側ではバイナリログを採取しておく必要があるので、Master側のmy.cnfにlog-binの設定が入っていることを確
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
現場指向のレプリケーション詳説
