Amazon Web Services ブログ Amazon Aurora PostgreSQL によるフェイルオーバー レプリケーション、フェイルオーバー、レジリエンス、災害対策、バックアップ—従来の、または非クラウドベースのアーキテクチャでは、これらの一部またはすべてを実現するのはとても困難です。さらに、時にはかなりのリエンジニアリング作業が必要になることがあります。関係する実装やインフラストラクチャのコストが高いため、一部の企業では最も重要なアプリケーションのみが適切に保護されるようにアプリケーションを階層化せざるを得ません。 こうした懸念は、Amazon Aurora for PostgreSQL に移行すること軽減できます。AWS は、Oracle、MySQL、PostgreSQL、Aurora を含む (ただしこれらに限定されない) 幅広い種類のリレーショナルデータベースエンジ
Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました!10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre
The PostgreSQL Global Development Group today announced the release of PostgreSQL 10, the latest version of the world's most advanced open source database. A critical feature of modern workloads is the ability to distribute data across many nodes for faster access, management, and analysis, which is also known as a "divide and conquer" strategy. The PostgreSQL 10 release includes significant enhan
はじめに PostgreSQLは商用DBに比べて書籍が少なく、まとまった情報が入手しにくいです。また、有志の方がPostgreSQLに関する資料を公開していますが、散在しており、せっかくの有益な情報にアクセスしにくい状況にあります。 そこで、本エントリではPostgreSQLの実行計画に焦点を絞り、公開されている有用な資料(書籍含む)をまとめました。読み返したい資料を探しやすくするため、内容のポイントも併せて紹介してます。 本エントリをきっかけに、これらの資料がさらに活用されることを願っています。 前提 各資料の前提としているPostgreSQLのバージョンは異なることにご注意ください。調査対象のPostgreSQLのバージョンが異なれば、状況は変わっているかもしれません。 各資料には内容の重複があり、ほぼ同一内容の場合もあります。重複している内容についてはポイントから割愛することがありま
2. 自己紹介 • 氏名下雅意美紀 • 所属TIS株式会社 • 経歴入社1年目 • PostgreSQL歴= 入社歴 • 業務で勉強する以外にも、前回のJPUGのしくみ分科会にも 参加したり(http://thinkit.co.jp/story/2014/07/01/5074)、 PGEConsにも参加したりとコミュニティ活動なども通して日々 PostgreSQLの勉強をしています。 2 3. PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~ アジェンダ ・PostgreSQLのクエリ実行の概要 ・Explain実行結果(問い合わせプラン)の読み方 ・Explain演算子の種類 ・問い合わせプランを変更させる ・実際のデバック例 3 目標 クエリチューニングで使用するExlpainコマンドが出力する実行 計画を読めるようになりましょう。 PostgreSQLがクエリ
去年書いたSoftwareDesignを題材にお話してください!って言われたので話してきました。 下の特集記事は1年経った今も現役で読める内容なので興味がある人はぜひ読んでみてください。 またRDBアンチパターンという連載をしていますのでこちらもあわせてご確認くださいっ! gihyo.jp そして当日の資料はこちらです。 SoftwareDesignにしっかりとMySQLとPostgreSQLの違いについては触れているのでそこでは触れていない、ハマりどころや初めて両方のDBを知ったと言う人向けのカジュアルは部分を攻めました。 またDBだけの勉強会ですので普段説明するようなところは省略し、できるだけ経験談やコアの話に注力したつもりです。 このへんは資料に含まれて居ないので当日居た人たちだけの特典ですね!! ということで実は今月は登壇3週連続だったのですが一段落しました。 来週はAWS Sum
数日前、Uberのブログで「Why Uber Engineering Switched from Postgres to MySQL」というエントリが公開されました。 Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog https://eng.uber.com/mysql-migration/ それに対して、PostgreSQLコミュニティ界隈でもいろいろなブログエントリが公開されました。 Robert Haas: Uber's move away from PostgreSQL http://rhaas.blogspot.jp/2016/08/ubers-move-away-from-postgresql.html On Uber’s Choice of Databases http:/
PostgreSQL 9.3正式版が公開。1秒以下の高速フェイルオーバー、データチェックサムによる高信頼性、マテリアライズドビューなどの新機能 「What's new in PostgreSQL 9.3」のページに並んだ項目から、主な新機能を抜き出してみました。 バルクロードの高速化のためのCOPY FREEZE カスタムバックグラウンドワーカー データチェックサム JSON機能の拡張 ラテラルジョイン イベントトリガー マテリアライズドビュー アップデータブルビュー 書き込み可能な外部テーブル 高速フェイルオーバー 過去のバージョンとの基本的な互換性は維持されています。 1秒以内でレプリカがマスターに昇格 高速フェイルオーバー機能では、レプリカデータベースがマスターへ昇格するのに1秒以内になるとのこと。 データチェックサムはページごとにデータのチェックサムを確認し、ストレージの障害などに
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
*【Linux】PostgreSQLのバックアップリストア手順 #contents **バックアップ データベースのバックアップ方法です。 #br +postgress のルートユーザでログイン コマンド # su - 例) # su - '''postgres''' #br +バックアップ postgres$ pg_dump -U postgres -F c -f HOGE_DB_BACK.car HOGE_DB **データベースのリストア データベースごとリストアする方法です。 #br +postgress のルートユーザでログイン コマンド # su - 例) # su - '''postgres''' #br +旧データベース削除(必要に応じて) リストア先の情報が残っている場合は、先に削除。 postgres$ dropdb <データベース名> 例) postgres$ drop
PostgreSQLのpg_dumpを用いたバックアップで困っています。 OSはVineLinux 2.2.17-0vl10です。 あるサーバ(PostgreSQL7.0.2)のデータベースtest_db(EUC_JP)に対して、 pg_dump -D -v -i -f test.dump test.db でダンプファイルを作成しました。 COPYでは不確実な場合があるということでINSERT文で出力しました。 (データの日本語の部分が数字に変換されています) それを別のサーバ(PostgreSQL8.2.5)のデータベースtest2_db(EUC_JP)にリストアしました。 psql test2_db < test.dump すると、"(株)"という文字を含む文字列が化けてしまっていました。 同じレコードの他のカラムは大丈夫です。 このような場合の対策がありましたら教えていただきたいと思
今回のおもな内容 ソースからインストール コンパイルとバイナリのインストール PostgreSQLの初期化 コマンドラインからデータベースを作成 データベースオブジェクトを操作する テーブルにデータを追加 select文で検索 psqlで使えるコマンド一覧 PostgreSQLは、LinuxやFreeBSDおよび一部の商用UNIXでは、パッケージシステムを用いて簡単にインストールすることも可能です。ただしRedHat系のLinux(RedHatやTurbo Linux、Vine Linuxなど)では、/usr直下のディレクトリ(/usr/binや/usr/lib)にファイルが配置されて、後でメンテナンスする場合などに少し戸惑いを感じるかもしれません(単に筆者だけかもしれませんが^^;;)。 そういうときは、ぜひともPostgreSQLをソースコードからコンパイルしましょう。その手順を紹介し
前のページでダンプしたデータの復元手順を示します。特に初めて復元作業を行われる方は、pg_dump や pg_dumpall で誤ったオプションが指定されれているとデータ消滅といった最悪の結果を招きます。 本格的な運用を前に、これらの作業を確認しておくことは大変重要です。データベースサーバを構築したら、事前にバックアップ、リストア作業に関してしっかり検証される事をおすすめします。 万が一の時の保険. PostgreSQLが実行するバックアップ、リストア作業はサービスを停止させないで実行できるメリットがありますが、前述したように初めての方は誤った操作で取り返しのつかない結果を招く可能性があります。 既に重要な情報がデータベース内に構築されている場合は、細心の注意が必要ですが、万が一の保険に備えてディレクトリ毎バックアップする方法もあります。原始的な方法ですが確実です。 PostgreSQL
PostgreSQLのバックアップ&リストア手法その1:使えば分かるPostgreSQL運用&チューニング(4)(2/3 ページ) pg_dumpの出力形式 出力形式はスクリプト形式とアーカイブ形式が選択できます。デフォルトはスクリプト形式で、バックアップ時のデータベースを復元するために必要なSQL文の羅列がプレーンテキストの形で出力されます。リストアはpsql コマンドを使用します。 スクリプト形式の利点は、なんといってもプレーンテキストという点です。例えば、リストアの際にエラーが発生した場合、ファイルの中身を見てエラーの原因を探ることができますし、PostgreSQL固有のSQL文を多少編集すれば、ほかのデータベース製品にもリストアすることができます。 一方、アーカイブ形式はバイナリの形で出力されます。リストアはpsqlではなく、pg_restore というリストア用のコマンドを使用し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く