ストリーミング・レプリケーション | Let's POSTGRES
ストリーミング・レプリケーション (Streaming Replication) は、PostgreSQL 9.0 以降で利用できる、本体組み込みのレプリケーション機能です。参照/更新が可能な1つのマスタDBへの更新操作を、参照のみが可能な複数のスタンバイDBへ転送することで、データベースを複製することができます。スタンバイDBに更新結果が反映されるまでには若干の遅延がありますが、比較的 遅延は少なく、マスタDBへの影響も小さいレプリケーション方式です。 用途 ストリーミング・レプリケーションには以下の用途があります。 多数の参照クエリのサーバ間分散 マスタDB異常時の迅速なフェイルオーバー (切り替え) マスタDBのディスク故障に備えたリアルタイム・バックアップ PostgreSQL 9.1 での強化点 バージョン 9.0 の目玉機能として登場したレプリケーション機能ですが、9.1 では
PostgreSQLのレプリケーション設定 - Just sleepy
PostgreSQLのドキュメントや他のサイトでもすでに設定例が掲載されていますが自分用のメモとして残します。 本設定はyum経由でPostgreSQL9.2をインストールしていることを前提とているので、もし参考にする場合は以前の記事に従ってPostgreSQL9.2をインストールしてください。 ■基本的な構成 マスターサーバ1台、スレーブサーバ2台。 マスタサーバはスレーブサーバ1台と同期レプリケーションを行い、もう1台とは非同期レプリケーションを行う。 ■マスタ側の設定 レプリケーション用のユーザ作成 $psql -U postgres CREATE ROLE レプリケーション用ユーザ LOGIN REPLICATION PASSWORD 'xxx'; PostgreSQLのdataディレクトリ配下にある設定ファイルをそれぞれ以下のように設定する。 (9.2をyum経由でインストールし
PostgreSQLレプリケーション徹底紹介
7. Copyright © 2012 NTT DATA Corporation 7 PostgreSQLレプリケーションの歴史 2007 2008 2009 2010 2012 2011 9.0(2010/9リリース) • 非同期レプリケーション 9.1(2011/9) • 同期レプリケーション • レプリケーション監視機能強化 • 物理バックアップ取得ツール 9.2(2012/9) • カスケードレプリケーション • スタンバイからの 物理バックアップ取得 • 同期モードの拡張 Slony-I Bucardo Londiste Sequoia PGCluster PostgresForest Postgres-R Mammoth PL/Proxy pgpool-II rubyrep Postgres-XC GridSQL syncreplicator レプリケーションツールが乱立! 当
26.1. Comparison of Different Solutions
Chapter 26. High Availability, Load Balancing, and Replication Shared Disk Failover Shared disk failover avoids synchronization overhead by having only one copy of the database. It uses a single disk array that is shared by multiple servers. If the main database server fails, the standby server is able to mount and start the database as though it were recovering from a database crash. This allows
26.2. Log-Shipping Standby Servers
Chapter 26. High Availability, Load Balancing, and Replication Continuous archiving can be used to create a high availability (HA) cluster configuration with one or more standby servers ready to take over operations if the primary server fails. This capability is widely referred to as warm standby or log shipping. The primary and standby server work together to provide this capability, though the
MySQL のレプリケーションを SSL でやってみました - ようへいの日々精進XP
要件 レプリケーションについて調べていたら脱線してレプリケーションを SSL 対応させてみた 構成 以下のような感じ。 インターネットを介して二台のサーバーで稼働している MySQL にてレプリケーションを行う。その際に SSL で通信を暗号化する。 手順 MySQL SSL 対応確認、設定 こちら を参考にマスター、スレーブともに MySQL を SSL 対応しておく スレーブ側も必要かは要確認 レプリケーションユーザー作成 マスター側のにレプリケーション用のユーザーを作成する。このときに注意するのは REQUIRE SSL オプション。 GRANT REPLICATION SLAVE ON *.* TO ${repl_user}@${slave_ip} IDENTIFIED BY '${your_password}' REQUIRE SSL; FLUSH PRIVILEGES; マスタ
Replica Shards | Elasticsearch: The Definitive Guide [2.x] | Elastic
WARNING: The 2.x versions of Elasticsearch have passed their EOL dates. If you are running a 2.x version, we strongly advise you to upgrade. This documentation is no longer maintained and may be removed. For the latest information, see the current Elasticsearch documentation. Up until now we have spoken only about primary shards, but we have another tool in our belt: replica shards. The main purpo
![Replica Shards | Elasticsearch: The Definitive Guide [2.x] | Elastic](https://cdn-ak-scissors.b.st-hatena.com/image/square/cbbc87b803e58787f8346841e5b65698d408f3c5/height=288;version=1;width=512/https%3A%2F%2Fwww.elastic.co%2Fstatic%2Fimages%2Felastic-logo-200.png){kind=logo}
MySQL レプリケーションのセットアップ手順 - わくわく技術ランド
想定していること † MySQL5.0 MySQLがすでに稼動中。レプリケーションの設定はしていない 今回MySQLをもう一台増やして2台構成とし、master、slaveの構成にする ※今回と状況が異なる場合は、MySQLのリファレンスマニュアルを読むといいです。 ↑ 1. レプリケーション用ユーザを作成する † レプリケーション用ユーザを作成する 作成するユーザーはスレーブがマスタのバイナリ ログを読み込むときに接続するユーザーとなる。 既存のユーザーでもレプリケーションは可能だが、ユーザ名とパスワードが master.info ファイル内にテキストで保存されるため、安全のためレプリケーションプロセスにだけ権限があるユーザを作成する 設定例(マスタのほうに設定) 192.168.23.0/24 内のネットワークで許可 ユーザー名：repl パスワード：slavepass mysql >
第6回 レプリケーション＋シャーディングでMongoDBをもっと使いこなす | gihyo.jp
概要 本連載では第4回ではレプリケーション、第5回ではシャーディングについて説明してきましたが、今回はレプリケーションとシャーディングを組み合わせた構成について紹介します。この構成を取ることにより、データを冗長化させつつも、分割して配置することができるため、可用性と読み取り性能を両方向上させることができます。 前回のシャーディングの構成では、単一のmongodをシャーディングサーバに割り当てていましたので、その1つのmongodが障害になると、シャーディングの機能が停止してしまうという問題がありました（図1参照）。 図1 これを解決するために、シャーディングサーバに単一のmongodではなくレプリカセットを割り当てます。これによりレプリカセット内のmongodに障害が発生してもシャーディングの機能が停止しない構成にすることができます（図2参照）。 図2 さらに信頼性を高めたい場合は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to change the number of replicas of a Kafka topic?
community.general.postgresql_user module — Ansible Community Documentation
Postgresql doesn't accept replication connection
PostgreSQLの同期レプリケーションを検証してみた | Tech-Sketch
様々な解法の比較
http://blog.flatlabs.net/20100316_233248/