PostgreSQL 9.2の同期レプリケーションを利用する際の勘所
DBMSの可用性とPostgreSQLのレプリケーション 勤怠管理やERPなど会社内の業務に欠かせないシステムはもちろんのこと、SNSやECサイトなど個人で利用するシステムでも、何かしらのDBMSを利用をするのが一般的です。 もしDBMSで障害が発生した場合、データの参照・更新が滞り、システム全体として役割を果たすことができなくなります。そのためユーザが利用したいときにシステムを利用可能にするためにはDBMSが継続的に稼働していることがとても重要です。 世の中にはDBMSは多数存在し、またDBMSの可用性を上げる機能やツールなどもさまざまに存在します。OSSの代表的なDBMSの一つであるPostgreSQLには可用性向上機能の一つであるレプリケーションが用意されています。 今回は最新バージョンであるPostgreSQL 9.2のレプリケーションについて、機能の紹介、利用時の注意点、設定によ
27.2. Log-Shipping Standby Servers
Chapter 27. 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
PostgreSQL Streaming Replication (ストリーミングレプリケーション)
クイックスタート 最も単純な構成でStreaming Replicationをセットアップする。 master、slaveとも同一サーバ上で動かす。ポート番号だけ変えて起動する(master=5432, slave=2345)。 マスタ 最低限の設定項目を示す。 # 啓蒙 shared_buffers = できるだけ大きな値 # これをonにしなければ始まらない。 archive_mode = on # archive か hot_standby。今回はHotStandbyと併用するので"hot_standby" wal_level = hot_standby # PITR用。適当なディレクトリを指定 archive_command = 'cp -i %p /home/postgres/archives_master/%f' # スレーブの最大数。ここでは1。 max_wal_sender
CentOS5.5上でPostgreSQL9.0のレプリケーションを試す - bose999の試験管の中の話
・プライマリサーバ 192.168.14.101/24 ・ホットスタンバイサーバ 192.168.14.102/24 まず、プライマリーサーバで作業を行ないます。 # su - postgres $ createdb -E UTF8 -O 'postgres' sample $ exit →テスト用のsampleデータベースをpostgresのものとして作成 # mkdir /var/lib/pgsql/9.0/archive # chown -R postgres:postgres /var/lib/pgsql/9.0/archive →アーカイブログの置き場所の作成 # vi /var/lib/pgsql/9.0/data/pg_hba.conf # vi /var/lib/pgsql/9.0/data/postgres.conf →内容については下記に記載したものを参照 # /etc
svnsync試してみた
svnsync は subversion repository の replication ツール。Subversion 1.4 から使える。よくバックアップって紹介されたりするけどバックアップと replication はなんか違うような気がする。RAID とバックアップが違うのと同じ感じかなぁ。 目的は忘れましたなんでこんなことをしようと思っていたか忘れました。なんかでも以下のようなことを考えていたような。 Capistrano は rsync による deploy もできるけど repository から取ってくるのがやっぱ王道？でも普段の commit 作業はローカルのサーバの方が速いし快適だしsvnsync 使えばいいの？実際にやってみた意外に準備が面倒。 sync 先を svnadmin で作るsync 先の repository を手作業で sync 先として準備（後述）sy
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
