wal_level (enum) wal_levelはどれだけの情報がWALに書かれるかを決定します。 デフォルト値はminimalで、クラッシュまたは即時停止から回復するのに必要な情報のみ書き出します。 archiveはWALアーカイビングに必要なロギングを追加し、hot_standbyは更にスタンバイサーバ上の読み取り専用問い合わせの情報を追加します。 このパラメータはサーバ起動時のみ設定可能です。 minimal水準では、同一のトランザクション内で作成されたり、切り捨てられたテーブル上のCREATE INDEX、CLUSTERおよびCOPYのような何らかの巨大な操作のWALロギングは安全を期して省略されます。そうすることで、一連の操作をより高速にさせます(項14.4.7を参照してください)。 しかしminimal WALはベースバックアップとWALログからデータを再構築するための充分
18.6. レプリケーション これらの設定は組み込みのストリーミングレプリケーション機能の動作を制御します(項25.2.5を参照ください)。 サーバ群のサーバはマスターかスタンバイのいずれかです。マスターはデータを送出する一方、複数のスタンバイは複製されたデータを常に受け取ります。カスケードレプリケーション(項25.2.6を参照)が使用されている場合、スタンバイサーバ群は受け取り手でもあり、送出先でもあります。 パラメータは主として送出先とスタンバイサーバ用ですが、いくつかのパラメータはマスターサーバのみに効力を発します。 必要とあればクラスターに渡って問題なく設定を変化させることができます。 18.6.1. 送出サーバ群 これらのパラメータはレプリケーションデータを1つ、またはそれ以上複数のスタンバイサーバに送るいかなるサーバ上で設定することができます。マスターは常に送出サーバであるため
25.2. ログシッピングスタンバイサーバ継続的なアーカイブ処理を使用して、プライマリサーバが失敗した場合に操作を引き継ぐ準備がなされた、1つ以上のスタンバイサーバを持つ高可用性(HA)クラスタ構成を作成することができます。 この機能はウォームスタンバイまたはログシッピングとして広く知られています。 プライマリサーバとスタンバイサーバは、この機能を提供するために共同して稼動しますが、サーバとサーバはゆるく結合しています。 プライマリサーバは継続的アーカイブモードで動作し、各スタンバイサーバはプライマリからWALファイルを読み取る、継続的リカバリモードで動作します。 この機能を可能にするために、データベースのテーブル変更は不要です。 したがって、他のレプリケーションの解法に比べて、管理にかかるオーバーヘッドが減少します。 この構成はプライマリサーバの性能への影響も相対的に減少させます。 ある
gariと申しますよろしくお願いします。 他トピックにもないようだったので、投稿いたします。 現在2台ののマシンでのストリーミングレプリケーション、walアーカイブの作成なし。 の構成および検証をやっています。 ところが、wal_keep_segments に関する記述がほとんどありません。 まず、環境としては CentOS 5.6にPostgreSQL 9.0.4なj構成です。 細かいスペックは分かりません。導入先の顧客のサーバ情報も分かりませんし、事前検証も VirtualBox上でやっています。 walアーカイブを作成しないときには、マスタのwal_keep_segmentsを大きくしろとあるのですが、 具体的にどれくらいのセグメントに対してとれくらいの値を設定すべきか検討が付きません。 http://www.postgresql.jp/document/9.0/html/wal-c
前回インストールしたPostgreSQL9.1で非同期レプリケーションを試します。 資料として【PostgreSQL9.0レプリケーション・ハンズオン - PukiWik】を参考にさせて頂きましたというか、ほとんどこのとおりにやってるので、最初からこちらを見られたほうがいいと思いますw マスター側の設定 マスターのデータディレクトリは前回同様"/usr/local/var/pgsql/data"です。 postgresql.confの設定 $ sudo vi /usr/local/var/pgsql/data/postgresql.confwal_level = hot_standby max_wal_senders = 4 wal_keep_segments = 16 "wal_level=host_standby" でマスタがスレーブからの接続を受け付けられるようにwad_levelに
はじめに AWSにはRDSというマネージドなデータベースサービスがあることは皆さんご存知だと思います。そこで提供されているデータベースは、MySQL、Oracle、SQLServerの3種類です。そうです、PostgreSQLが無いのです!ナイナイ詐欺のAWSなので、そのうち出てくると思いますが、今のところはありませんので、自前で構築する必要があります。せっかく構築するなら、オンプレのコピー感覚で使うのではなく、クラウドネイティブに使いたいものです。今回は、そんなPostgreSQLをEC2上で構築するために考えるポイントをまとめたホワイトペーパーをベースに理解を深めたいと思います。 PostgreSQL on Amazon EC2 PostgreSQLは、ACID(Atomicity:原子性, Consistency:一貫性, Isolation:独立性, Durability:永続性)
空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ -空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ - postgresqlグループ.の元エントリを読んで思うところがあったのだが、 PostgreSQLを高速化する16のポイント だからそんなせまっくるしいところでトンチンカンにdisる暇あるんだったら自分のブログでお好みの議論を書くかさもなきゃ/dev/nullにでも吐けとやんわりと言ってるんだよハゲ。 というわけでw。 だよねw。 まあ正直、上記元ネタのほうには色々突っ込みどころ満載なのだが、それは置いておくとしてL.starなりの高速化ポイントを一度書いておかないと、と思ったので記す。ただ、L.starはもうPostgreSQL界隈から離れて久しいので、必ずしも最新の内容を網羅していないことに注意されたし。また、出来るだけPos
Last Updated on: 2018年8月13日PostgreSQL Advent Calender 2013、13日目のエントリです。 表題の通り「タグ検索するならPostgreSQLで決まり!」です。 追記:JSONの場合はPostgreSQLのJSONB型を利用してタグ検索を行うを参照 RDBはタグが苦手 WebアプリではRDBでは取り扱いづらいデータを取り扱う事がよくあります。タグの管理・検索はその一つです。 RDBはタグ情報の管理・検索をしっかりやれますが、どちらかと言うと苦手な分野です。しかし、PostgreSQLの 配列 GIN(Generalized Inverse Index – 転置インデックス) を使うと簡単かつ高速に処理できます。 PostgreSQLを使うとタグ検索が簡単・高速に実現できますが、Googleで「タグ検索 PostgreSQL」と検索しても全く
回線が細くCPUも弱いスマートフォンは、リッチなWebサイト表示が苦手です。しかし、地道な対策で表示速度が驚くほど変化するのも事実。 今回はスマホのWebサイト表示の高速化手法をまとめました。もちろんPC向けにも効果バツグンのTips集です。 Webサイトを劇的に高速化する9つのポイント 1.画像を圧縮する 2.画像はサイズを指定して使う 3.画像は適切なサイズで使う 4.CSS/JavaScriptを圧縮する 5.CSSスプライトを使う 6.不要なCSS/JavaScriptを読み込まない 7.CSS/JavaScriptをまとめる 8.CSSセレクターを最適化する 9.mod_deflateでgzip圧縮する 1.画像を圧縮する 画像を最適化することは、フロントエンドの高速化に絶大な効果を発揮します。Photoshopを使って圧縮しても良いのですが、もっと手軽に圧縮
先日、Yahoo! ニュースからリンクして頂いたのを切っ掛けに、大量アクセスがありました。いつもは後で気がつくんですけど、たまたま Google Analytics のリアルタイム画面を開いたらその直前にアクセスが爆発していました。通称「Yahoo!爆弾」ってヤツですね。 【追記】現在はコアウェブバイタル対応を完璧にするため、もっとモダンな設定にしています。 iPhone 研究室は WordPress で運営していますが、全く動じないでこの大量アクセスをこなしてくれました。 11時半頃にリンクがあったみたいなんですけど、世の中がお昼休みに入った12時頃から更にアクセスが倍増しました。 だいたい、11時半から12時までの30分で2万ページビュー(PV)、12時から13時までの1時間だけで5万PV位の大量アクセスになりました。 新型iPhoneに関する噂という記事からのリンクだったので、興味を
はじめに はじめまして、こんにちは。クラスメソッド株式会社でWebを担当している野中です。 この度、「これから身につけるWebサイト高速化テクニック」と題して記事を連載させていただくこととなりました。 本連載ではWeb担当者やWebデザイナー、コーダーの方々に向けて高速化に関する手法や技術について調べ、身につけたテクニックを細かな解説を加えて紹介していきます。中には少し難しいテクニックも含まれますが、できる限り分かりやすく、すぐに実践できるよう紹介していきたいと思います。とても長い連載ですが、よろしくお願いいたします。 なお、本連載はクラスメソッド開発ブログで連載されている「身につけておきたいWebサイト高速化テクニック」の増補改訂版です。 本連載の流れ 本連載はできるだけ多くの方に興味を持っていただけるように、最初に高速化対策の全体像と必要な知識を紹介します。その後、具体的な高速化対策と
Windows7のSNPという機能を無効化することにより安定化・速度向上が見込める。 ■スペック ・OS : Win7Pro SP1 64bit ・マザー : BIOSTAR TA780G M2+ ・ネットワークアダプタ : オンボード Realtek PCIe GBE Family Controller ドライババージョン : 7.40.126.2011 ■SNPを無効化する手順 1.コマンドプロンプトを管理者権限でひらく 2.現在の設定を確認 >netsh int tcp show global 3.TCP Chimney Offload の無効化 >netsh int tcp set global chimney=disabled 4.Receive-Side Scaling(RSS)の無効化 >netsh int tcp set global rss=disabled 5.Netw
Windows 7のネットワーク設定を標準で使ってはいけない。標準では「SNP(Scalable Networking Pack)」と呼ばれるネットワークを最適化する機能が有効化されている。この「SNPが有効化」されている設定のままPCを動作させると、ネットワーク処理が不安定になったり、ネットワーク処理とは関係ないアプリケーションの処理に影響を与えたりする可能性があるからだ。 SNPとは、通常はPC上のプロセッサが行っているネットワーク処理を、PC内部のNIC(ネットワークインタフェースカード)に担当させるなどしてプロセッサの負荷を下げる機能だ。 ハードにネットワーク処理を分担させるSNP SNPは三つの機能からなる。「SNPが有効」とは三つのうち、少なくとも一つが有効化していることを指す。 (1)TCP Chimney Offload TCPのネットワーク制御をプロセッサからNICにオフ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
Grokking V8 closures for fun (and profit?) に、ほんの少しだけ触れられている話なんですが。 ごく最近まで V8 には、オブジェクトリテラルの中で関数リテラルを使った場合に非常に遅くなる(というかGCが多発する)問題があった。 たとえば、 function doit() { for (var i = 0; i < 1000; ++i) { for (var j = 0; j < 1000; ++j) { var o = { f: function () { return i + j; } }; } } } doit(); というコードを node-0.6.19 で実行すると、以下のように mark-sweep GC が大量に発生して処理に時間がかかっていることが分かる。 $ time /usr/local/node-0.6.19/bin/node -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く