タグ付けされた質問 「postgresql」

PostgreSQLは、強力なオープンソースのオブジェクトリレーショナルデータベースシステムです。15年以上の活発な開発と実証済みのアーキテクチャを備えており、信頼性、データの整合性、正確性で高い評価を得ています。Linux、UNIX(AIX、BSD、HP-UX、SGI IRIX、Mac OS X、Solaris、Tru64)、Windowsなど、すべての主要なオペレーティングシステムで動作します。

2
ファイルI / OなしでPostgresが95%アイドル状態になっているのはなぜですか?
OpenStackクラウドの8コアUbuntu 12.04 VMでTileMill / PostGISスタックを実行しています。これは非常によく似たシステムを再構築したもので、先週非常によく似たハードウェア(同じクラウドですが、物理的なハードウェアが異なると思います)でうまく動作していました。私はそれとまったく同じようにスタックを再構築しようとしました(構築したいくつかのスクリプトを使用)。 すべてが実行されますが、データベースは非常にゆっくりとクエリを実行します。これは、最終的に非常に遅いタイルの生成で現れます。以前は10〜20秒程度かかっていたクエリの例(オーストラリアのすべての町の半径内にあるパブの数を数える)は、今では10分以上かかっています。 explain (analyze, buffers) update places set pubs = (select count(*) from planet_osm_point p where p.amenity = 'pub' and st_dwithin(p.way,places.way,scope)) + (select count(*) from planet_osm_polygon p where p.amenity = 'pub' and st_dwithin(p.way,places.way,scope)) ; Update on places (cost=0.00..948254806.93 rows=9037 width=160) (actual time=623321.558..623321.558 rows=0 loops=1) Buffers: shared …

2
pg_dumpのリソースを貪欲にする方法
次のルールを使用して、pg_dumpを毎日呼び出すようにcronを構成しました。 # xyz database backups: 00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/`date -u +\%Y\%m\%dT\%H\%M\%S`.gz 基本的には動作します。データベースは比較的速く、指数関数的に成長します(ただし、指数はそれほど大きくありません)。現在、gzipされたダンプには約160MB必要です。データベースがダンプされると、システムはクロールを開始します。topコマンドを使用して見た負荷平均は約200, 200, 180でした。基本的に、サーバーはほとんど応答しません。 最初の質問は、ボトルネックがどこにあるかを決定する方法です。パフォーマンスの低下は重いI / O操作が原因ですか?テーブルロックの問題が原因ですか?多分それはメモリの問題ですか?pg_dumpコマンドの出力はコマンドにパイプされgzipます。それは順次ですか、つまり、ダンプ全体がメモリに配置され(スワッピングの問題ですか?)、次に圧縮されますか、それとも並行ですか(つまり、gzipは取得したものを圧縮し、それ以上待機します)?他の原因が考えられますか? 2番目の質問は、システムの主な機能のためのダンプ操作は控えめにする方法です。私が理解している限りでは、データベースの整合性のため、ダンプに時間がかかることはありません。テーブル書き込みロックなどがあります。問題を制限する(またはデータベースの成長を考慮して遅延させる)にはどうすればよいですか。 3番目の質問は:すでに、より高度なデータベース構成について学ぶ時期ではありませんか?データベースのバックアップが実行されていない場合、システムは正常に動作しますが、おそらくデータベースダンプの問題が着信問題の最初の症状ですか?

3
PostgresとMySQL:スケールアウトが難しいのはどれですか?
あなたの経験から、どのデータベースはスケーリングが難しいですか?MySQLまたはPostgres?MySQLには、すぐに使えるスケーリング/クラスタリング機能がいくつかありますが、Postgresには、すぐに使えるものはありません。CMIIW。 編集: ここで混乱して申し訳ありませんが、私の質問は、スケールアウト(水平スケーリング)、つまりクラスタリング、シャーディングなどに言及しています。どちらも水平方向にスケーリングできることはわかっていますが、どちらを実装する方が簡単ですか? 共有してくれてありがとう。

7
MySQLはPostgreSQLよりも優れていますか?
質問は挑発的に聞こえますが、実際はそうではありません。最近、多くの分野でMySQLの制限が見つかり、PostgreSQLがますます好きになっています。これは、MySQLよりもはるかに優れたスケーリングとSQL標準への準拠を実現しています。 私はまだPostgreSQLの世界に不慣れですが、将来のすべてのプロジェクトでMySQLから離れることをいとわないので、知りたいことは、MySQLの特定の機能が優れていることですPostgreSQLよりも高性能またはよりユーザーフレンドリーなど)? 私はMySQLから何を逃してしまうのだろうと思っています。MySQLのAUTO_INCREMENTフィールドはPostgreSQLのSEQUENCESよりも便利であり、Windowsでの展開は以前から問題がありました(問題ではなくなりました。私にとっては問題ではありません)。 ほかに何か?
8 mysql  sql  postgresql 

4
PostgreSQLデータベースをMS SQL 2005に移行するのに最適なツールですか?
テーブルスキーマとデータの両方を含め、MS SQL Server 2005(またはおそらく2008)に移行したいPostgreSQL 8.3.1のデータベースがあります。データベースのサイズは約50GB、行数は約400,000,000なので、単純なINSERTステートメントは問題外だと思います。誰もがこの移行を実行するための最良のツールを推奨できますか?明らかに信頼性が必要であり、データはターゲットDBでもソースDBでもまったく同じであり、このボリュームのデータを妥当な時間内にコピーできる必要があります。



1
大きなデータベース(postgres)をローカルコピーにダウンロードする
Amazon RDSには非常に大きなpostgres DB(zip形式で約9GB)があり、ローカルマシンでそれをコピーしてテストする必要がある場合があります。 DBダンプ(pg_dump)を実行してダウンロードするのは遅すぎるだけで、正直に言って最後に何度か行き詰まってしまいました。 DBの一部をスマートな方法で取得する簡単な方法はありますか?たとえば、過去10日間の変更のみを取得してから、それらをローカルDBとマージできますか、またはDBをチャンクなどで取得できますか? 私はその必要性を持つ最初の人ではないと確信していますが、それを行うための最良の方法を説明するまともな方法やチュートリアルを見つけることができませんでした。 ありがとう!

1
Postgres 9.5-main.pg_stat_tmp:そのようなファイルまたはディレクトリはありません
数か月前に(詳細を忘れてしまったために)さまざまな状況下でこの問題に遭遇しました。この問題をグーグルで検索した場合、同様の投稿が多数ありますが、満足のいく結論の多くに到達するものはありません。単に許可ベースである場合を除き、これがそうであることを確認するのに苦労しています。 データベースの復元が必要と判断された場合に実行されるDebian init.dスクリプトからpostgresサービスを停止および開始しています。 問題なく停止します。 systemctl stop postgresql 復元操作はスムーズに実行されます(pgbackrest、リモートでホストされるスタンザバックアップ): sudo -u postgres bash -c "pgbackrest --log-level-console=info --stanza=$stanza --delta restore" 次に、デバッグまたはログが生成されずに開始操作がハングします。 systemctl start postgresql systemctlの呼び出しをpostgresの直接呼び出しに置き換えた場合: sudo -u postgres bash -c "/usr/lib/postgresql/9.5/bin/postgres -D /var/lib/postgresql/9.5/main -c config_file=/etc/postgresql/9.5/main/postgresql.conf 次のエラーが表示されます(タイムスタンプは無視してください。これは私が使用しているテストボックスです)。 2016-11-03 17:30:27 UTC [2511-3] FATAL: could not open directory "/var/run/postgresql/9.5-main.pg_stat_tmp": No such file or directory 次に指摘することは、Postgres …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.