PostgreSQL 9.0 の新機能 — Let's Postgres
2010年9月20日、PostgreSQL 9.0.0 がリリースされました。"バージョン 9" を冠する記念すべきリリースです。リリースアナウンスによると、9.0 には組み込みのレプリケーションを始め、数多くの新機能が盛り込まれていると述べられています。バイナリやソースコードは "ダウンロード用ページ" で配布されています。 9.0 では、ホット・スタンバイとストリーミング・レプリケーションを併せて「参照負荷分散レプリケーション」を構成することができます。この記事では、このレプリケーションの概要と、その他の PostgreSQL 9.0 の新機能について紹介します。 参照負荷分散レプリケーション PostgreSQL 9.0 には「ホット・スタンバイ」と「ストリーミング・レプリケーション」が採用され、これらを組み合わせることで、PostgreSQL でシングルマスタ - マルチスレーブ型
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
MySQL Multi-Master Replication Manager [mysql-mmm]
NOTE: By now there are a some good alternatives to MySQL-MMM. Maybe you want to check out Galera Cluster which is part of MariaDB Galera Cluster. MMM (Multi-Master Replication Manager for MySQL) is a set of flexible scripts to perform monitoring/failover and management of MySQL master-master replication configurations (with only one node writable at any time). The toolset also has the ability to r
rubyrep: Home
Mission Development of an open-source solution for asynchronous, master-master replication of relational databases that is ridiculously easy to use database independent[1] License Released as open source under the MIT license. Status Production ready. Battle tested. Main Features Can scan two databases for differences Can sync two databases Can continuously replicate between between two databases
Repcached
repcachedについて repcachedとは、memcachedにデータのレプリケーション機能を追加実装したものです。 memcachedは、以下のようなところによく使われると思います。 一時的なデータの保存場所として キャッシュを保存する場所として RDBMSのデータのキャッシュ 生成したページデータのキャッシュ いずれの場合も消えていいデータなので、万が一memcachedがダウンしても問題はないはずです。 しかし、影響が全くないわけではありません。 例えば、MySQLのデータをmemcachedでキャッシュしている場合、memcachedがダウンしている間は直接MySQLにアクセスがいくことになりDBサーバの負荷が上がります。また、memcachedを再起動してキャッシュが失われた場合は、再びキャッシュが溜まるまではDBサーバに負荷がかかることになってしまいます。 このように
DSAS開発者の部屋:repcached 1.0をリリースしました！
repcached初の公開バージョンとなる1.0を公開しました。 http://lab.klab.org/modules/mediawiki/index.php/Repcached (日本語) http://repcached.lab.klab.org/ (英語) repcachedとは、memcachedに以下の機能を追加するプロダクトです。 アクティブ/バックアップ構成での自動的なフェイルオーバ 無停止のフェイルバック 「キャッシュサーバなのに冗長構成って必要なの？」と思うかもしれませんが、そのあたりの開発動機も含め、インストール方法などのドキュメントは上記のプロジェクトページにありますのでご覧くださいませ！ 追々、このブログでも活用事例を紹介していきたいと思っています。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Art of MySQL Replication.
現場指向のレプリケーション詳説