Amazon Web Services ブログ

Category: RDS for PostgreSQL

RDS PostgreSQL トランスポータブルデータベースを使用したデータベースの移行

Amazon RDS for PostgreSQL が、バージョン 11.5 以降および 10.10 以降で、高速データのインポートおよびエクスポート方法であるトランスポータブルデータベース機能をサポートするようになりました。RDS PostgreSQL インスタンスから別の PostgreSQL インスタンスに PostgreSQL データベースをインポートする必要がある場合は、pg_dump や pg_restore などのネイティブツールを使用するか、\copy コマンドを使用してデータをターゲットテーブルにロードできます。トランスポータブルデータベースを使用すると、こうした従来のツールよりもはるかに高速にデータを移動することができます。この機能は、データベースごとの物理的な転送メカニズムを提供する pg_transport と呼ばれる新しい拡張機能を使用します。物理的な転送では、最小限の処理でデータベースファイルをストリーミングすることにより、最小限のダウンタイムでデータをより高速に移動できます。 この記事では、pg_transport の一般的なユースケースと、AWS CLI と psql ユーティリティを使用して RDS PostgreSQL 環境でこれを設定および使用する方法について説明します。 pg_transport のユースケース 多くのお客様は、RDS PostgreSQL で独自の SaaS またはマルチテナントおよびエンタープライズアプリケーションを実行しています。これは、Amazon RDS により、AWS での PostgreSQL デプロイの設定、操作、スケーリングが簡単になるためです。単一の RDS PostgreSQL インスタンスに複数のデータベースを配置して、さまざまな顧客やアプリケーションにサービスを提供するのは一般的なことです。このような環境では、トランスポータブルデータベースが役立ちます。 以下のようなユースケースに最小限のダウンタイムで対処できます。 リソースの管理や分離を改善するために、RDS インスタンス間でデータベースを移動する。たとえば、SaaS プロバイダーであれば、特定の容量に達した場合、顧客データを異なる構成 (より大きなインスタンスタイプ、プロビジョンド IOPS、または異なるインスタンスファミリー) に移動する必要があります。 セキュリティおよびコンプライアンスの理由でデータを再編成する。たとえば、ある AWS アカウントの […]

Read More

RDS および Aurora PostgreSQL ログの操作: パート 2

このシリーズの最初の投稿である RDS および Aurora PostgreSQL ログの操作: パート 1 では、PostgreSQL のログの重要性と、より多くのデータベースアクティビティの詳細情報をキャプチャするためのさまざまなパラメータを調整する方法を記載しています。PostgreSQL ログは、データベースの問題を解決するのに役立つ情報を提供します。この投稿は、PostgreSQL ログにアクセスするためのさまざまな方法に焦点を当てています。 PostgreSQL ログはクラスターの各インスタンスに生成および保存されます。これらのログファイルにアクセスする方法は複数あります。以下のセクションでは、これらの方法をいくつか説明します。 AWS マネジメントコンソールにアクセスする PostgreSQL ログファイルにアクセスするための最も直接的な方法は、AWS Management Console を介して行います。以下の手順を実行します。 Amazon RDSを開きます。 RDS/Aurora インスタンスを選択します。 [ログとイベント] を選択します。 [Logs] で必要なログファイルを選択します。 [View]、[Watch]、または[Download]のいずれかを選択します。 以下のスクリーンショットは、[Logs] セクションのプレビューです。 これは、ログファイルを表示またはダウンロードするための最も基本的な方法です。 CloudWatch Logs にログファイルを発行する RDS および Aurora PostgreSQL は、Amazon CloudWatch Logs へのログの発行をサポートしています。詳細については、RDS ユーザーガイドの「PostgreSQL ログの Amazon CloudWatch Logs への発行」を参照してください。 ログが CloudWatch Logs の場合、アラームを作成し、リアルタイム分析を行うことができます。たとえば、log_statements を […]

Read More

RDS および Aurora PostgreSQL ログの操作: パート 1

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30 年以上におよぶ開発作業を経ている PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。AWS は 2 つのマネージド型 PostgreSQL オプションを提供しています。Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL です。デバッグやモニタリングのためのデータベースアクティビティログをどのようにキャプチャするのかという質問が、新規の PostgreSQL ユーザーから多く寄せられます。この記事では、RDS および Aurora PostgreSQL を設定して追加のエンジンログを生成する方法について説明します。記事の第 2 部である RDS および Aurora PostgreSQL ログの操作: パート 2 では、これらのログファイルにアクセスする方法をご紹介します。 PostgreSQL は、データベース管理者 (DBA) に役立つ情報を含むイベントログを生成します。デフォルトでは、SQL クエリエラー、ログイン試行の失敗、デッドロックがデータベースログにキャプチャされます。これらのエラーメッセージはアプリケーションのさまざまな問題の特定に役立ちます。たとえば、レガシーアプリケーションを Oracle から PostgreSQL に変換すると、一部のクエリが PostgreSQL 構文に正しく変換されないことがあります。こうした誤った形式のクエリによってログにエラーメッセージが生成されるため、問題のあるアプリケーションコードを特定するのに役立ちます。 デフォルトのログ記録を使用するだけでなく、PostgreSQL ログ記録パラメータに変更を加えれば、パフォーマンスの低下やセキュリティ監査などの問題を特定、解決するのに役立つ情報を取得できます。このログ記録パラメータを設定すると、接続と切断、スキーマ変更クエリ、すべてのスロークエリとその時間、ロックのため待機中で時間がかかるクエリ、一時的なディスクストレージを消費するクエリ、リソースを消費するバックエンド自動バキュームプロセスなどの情報をキャプチャできます。 このログ情報は、データベース使用中の潜在的なパフォーマンスと監査の問題をトラブルシューティングするのに有用です。この記事では、このログ記録の有効化とその利点について詳しく説明します。 DB パラメータグループ RDS および Aurora […]

Read More

Amazon RDS for PostgreSQL バージョン 9.4.x のリタイアメントのお知らせ

本投稿は、こちらのフォーラムに投稿された Amazon RDS for PostgreSQL をご利用中のお客様向けのアナウンスメントの参考和訳です。 本投稿は、PostgreSQL コミュニティが2020年2月にバージョン9.4を廃止予定であることに従い、2020年1月15日をもって、Amazon RDS が RDS for PostgreSQL 9.4 のサポートを終了することをお知らせするものです。 Amazon RDSは2015年からPostgreSQLメジャーバージョン9.4をサポートしています。本リリース後、機能性、セキュリティ、信頼性、パフォーマンスの観点で大幅な改善がなされたメジャーバージョンが続々とリリースされています。PostgreSQLコミュニティは、PostgreSQL 9.4のリリース終了時期を2020年2月と発表しています。コミュニティサポートモデルに沿って、AWSは9.4.1, 9.4.4, 9.4.5, 9.4.7, 9.4.9, 9.4.10, 9.4.11, 9.4.12, 9.4.14, 9.4.15, 9.4.17, 9.4.18, 9.4.19, 9.4.20, 9.4.21, 9.4.23 のマイナーバージョンを含む、メジャーバージョン9.4のサポートを終了いたします。Amazon RDS では引き続き、バージョン9.5 以降の PostgreSQLデータベースをサポートいたします。 できるだけ早いタイミングで、Amazon RDS PostgreSQL 9.4 データベースインスタンスをバージョン9.6, 10 もしくは、バージョン11 にアップグレードすることを推奨します。9.5 へアップグレードすることも可能ですが、このバージョンは2021年2月にサポート終了が予定されています。 利用中の PostgreSQL 9.4 のマイナーバージョンと PostGIS 拡張の利用有無に応じて、バージョン10 もしくは、11 に直接アップグレードできる可能性があります(※訳者注: […]

Read More

Amazon RDS Under the Hood: Multi-AZ

Amazon Web Services (AWS)のお客様はデータストアと、そのデータストアの高可用性にお客様のビジネスを委ねています。そのようなお客様に向けて、Multi-AZ配置は高可用性を実現する方法を容易に提供します。 Amazon Relational Database Service (Amazon RDS)でMulti-AZを有効にすることで、データの冗長かつ一貫した状態を維持します。もし、primaryデータベースサーバに問題が発生した場合は、standbyデータベースサーバに自動的に変更しデータへアクセスし続けられるようにします。2つのデータのコピーはそれぞれ別のAvailability Zones (AZs)内で管理されています(そのため、Multi-AZと呼ばれています)。別々のAvailability Zones を持つことで、両方のデータが同時に障害に見舞われるリスクを軽減させています。データの適切な管理、簡単な再構成、およびコピーへの信頼できるユーザーアクセスは、顧客環境が要求する高可用性要件に対処するための鍵です。 この投稿では、MySQL、MariaDB、PostgreSQL、およびOracleデータベースインスタンスのAmazon RDS Multi-AZ設定について説明します。Amazon RDS for SQL ServerおよびAmazon Auroraは、異なるテクノロジースタックを使用してマルチAZ機能を提供します。 基本デザイン Mult-AZ機能はデータベースアプリケーションとAmazon Elastic Block Store(Amazon EBS)ボリュームの間にあるレプリケーションレイヤーを使用して実装されています。このレイヤーは、アプリケーションの読み取りおよび書き込み要求を処理し、2つの個別のEBSボリュームコピーがある環境に適用されます。1つはローカルアクセス、もう1つはリモートアクセスです。 通常時は、レプリケーションレイヤーがインストールされた、2つのアクティブなAmazon EC2インスタンスがあります。 各インスタンスは、データの完全なコピーが行われているEBSボリュームを管理しています。この構成により、2つのインスタンスとそのボリュームがMulti-AZデータベースインスタンスとして稼働しています。 レプリケーションレイヤーは、TCP接続を介して互いに直接通信を行っています。 各インスタンスには特定のロールが割り当てられます。1つはプライマリであり、ユーザーがデータにアクセスするための外部エンドポイントを提供します。もう1つはスタンバイであり、プライマリから受信するすべてのデータを同期的に書き込むセカンダリインスタンスとして機能します。データベースの書き込みは、正常応答が呼び出し側アプリケーションに送り返される前に、データが両方のボリュームに適切に書き込まれます。ただし、読み取り操作は常にプライマリEBSボリュームを介して実行されます。データベースサーバープロセスは、スタンバイインスタンスで実行されていないため外部エンドポイントは公開されません。そのため、ユーザーはstandbyデータベースインスタンス上のデータのコピーは使用できません。 可用性を向上させるためにMulti-AZは、インスタンスの1つがプライマリロールにあることを一貫して保証し、データのコピーへのアクセスを提供します。もし可用性の問題が発生した場合、スタンバイインスタンスを自動的にプライマリロールに昇格させ、リダイレクトによって可用性を復元させます。 このイベントは、フェイルオーバーと呼ばれます。旧プライマリがまだ稼働している場合、スタンバイロールに降格されます。 新しいプライマリインスタンスへのリダイレクトは、DNSを介して提供されます。クライアントDNSクエリの結果に含まれるレコードのTTLは非常に短くなっています。アドレス情報の長期間のキャッシングを禁止することを目的としています。これにより、クライアントはフェールオーバープロセスで情報をより早く更新し、DNSリダイレクトの変更をより迅速に取得します。 以下の図が正常時のMulti-AZインスタンスの状態を示しています。 Figure 1: Multi-AZ instance データベースアプリケーション(黄色で表示されるDB APP)は、DNS)オレンジ色で表示)使用して、データへのアクセスを提供している現在の外部エンドポイントのアドレス情報を取得します。 このマルチAZインスタンスには2つのRDS DBインスタンスがあります。プライマリインスタンス(左側に緑色で表示)とスタンバイインスタンス)右側に青色で表示)です。この例では、DNSはアプリケーションをプライマリインスタンスEC2#1に向けており、Availability Zone#1で利用可能なEBS#1のプライマリコピーを提供しています。2つのEC2インスタンスの複製レイヤーが接続されています。アプリケーションが発行する書き込み操作は、2番目のインスタンスへの書き込みにもなります(パスは灰色で表示)。 レプリケーションレイヤーは、それ自体の可視性が制限されているため、より詳細な決定を下すことができません。たとえば、クライアントからの接続問題、ローカルまたはregionの停止、または予期せずサイレントな状態になったEC2ピアの状態などを知るすべがありません。このため、2つのインスタンスは、より重要な情報にアクセスし、インスタンスのステータスを定期的に監視する外部システムによって監視および管理されています。必要に応じて、管理システムは、可用性とパフォーマンスの要件が満たされてるためのアクションを実行します。 Multi-AZが提供する可用性と耐久性の改善は、最小限のパフォーマンスコストで実現しています。通常の使用例では、レプリケーションレイヤーが接続され、スタンバイEBSボリュームへの同期書き込み操作が発生します。スタンバイインスタンスとボリュームは、地理的に離れた個別のAvailability Zoneに配置されています。評価では、データベースのコミットへのオーバーヘッドが2ミリ秒から5ミリ秒増加していることが示されています。ただし、実際の使用例に対する実際の影響は、ワークフローに大きく依存します。ほとんどのお客様のMulti-AZインスタンスは、影響があったとしてもパフォーマンスにわずかな影響を示します。 この設計により、AWSはお客様のデータに対して99.95%の可用性を超えるサービスレベルアグリーメント(SLA)を提供しております。詳細については、Amazon RDSサービスレベルアグリーメントをご覧ください。 実装について ボリューム複製機能の設計は単純で簡単だと思われるかもしれません。しかし、実際の実装はかなり複雑です。これは、絶えず変化し、時には大きく変動する環境内で、2つのネットワークで接続された個別のインスタンスおよびボリュームが遭遇する可能性があるすべての事象を考慮する必要があるためです。 通常の進行中のレプリケーションは、すべてが適切に機能し、正常に動作していることを前提としています。EC2インスタンスが利用可能で、通常のインスタンス監視が機能し、EBSボリュームが利用可能で、ネットワークが期待どおりに動作しています。しかし、これらのピースの1つ以上が誤動作しているとどうなるでしょうか? 発生する可能性のある問題とその対処方法を見てみましょう。 […]

Read More

Amazon RDS PostgreSQL レプリケーションのベストプラクティス

Amazon RDS for PostgreSQL では、読み込み負荷を取り除き、災害復旧 (DR) リソースを作成するために、ソース PostgreSQL インスタンスのレプリカを簡単に設定することができます。リードレプリカは、ソースと同じリージョン、または異なるリージョン内に設定できます。 RDS PostgreSQL リードレプリカインスタンスを使用すると、読み込みワークロードをレプリカインスタンスにオフロードすると同時に、書き込みアクティビティのためにソースインスタンスのコンピューティングリソースも確保します。ただし、レプリケーション遅延を避けるには、リードレプリカを正しく設定し、適切なパラメータ値を設定する必要があります。 概要 この記事では、リードレプリカを正しく設定するためのベストプラクティスをいくつかご紹介します。リージョン内、クロスリージョン、および論理レプリケーションなどのさまざまな RDS PostgreSQL レプリケーションオプションの長所と短所を取り上げ、適切なパラメータ値と、監視するメトリクスを推奨します。以下のステップでは、レプリケーション遅延を最小限に抑えながら、DR 戦略、読み込みワークロード、および健全なソースインスタンスを最適化する方法を説明します。 一般的な推奨事項 全体的なベストプラクティスとして、リードレプリカで実行するリードクエリが、ソースインスタンスとしてデータの最新バージョンを使用することを確認してください。データバージョンは、Amazon CloudWatch メトリクスでレプリケーション遅延を調べることによって確認できます。レプリケーション遅延を最小限に抑えることによって、古いデータに基づいたクエリ出力と、インスタンスの健全性に対するリスクの両方を避けることができます。 リージョン内のレプリケーション RDS PostgreSQL は、ソースインスタンスと同じ AWS リージョン内でリードレプリカを作成するために Postgres ネイティブストリーミングレプリケーションを使用します。ソースインスタンスでのデータの変更は、ストリーミングレプリケーションを使ってリードレプリカにストリームされます。このプロセスが何らかの理由で遅れると、レプリケーション遅延が発生します。以下の図は、RDS PostgreSQL が同じリージョン内のソースとレプリカの間でレプリケーションを実行する方法を示しています。 この後のセクションでは、同じリージョン内でホストされている RDS PostgreSQL インスタンスを最適にレプリケートするために Postgres インスタンスを調整する方法について説明します。 適切な wal_keep_segments の値 Postgres では、wal_keep_segments パラメータで pg_wal ディレクトリに保存される WAL ログファイルセグメントの最大数を指定します。Postgres は、このパラメータを超える WAL セグメントを Amazon S3 バケットにアーカイブします。 リードレプリカが […]

Read More

PostgreSQL ユーザーとロールの管理

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30 年以上の開発作業を経て、PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。アマゾン ウェブ サービス(AWS)は、管理された 2 つの PostgreSQL オプションを提供します:PostgreSQL および Amazon Aurora PostgreSQL 用の Amazon Relational Database Service(Amazon RDS)。この記事では、PostgreSQL でユーザーとロールを管理するためのベストプラクティスについて説明しています。 PostgreSQL を使用すると、きめ細かいアクセス権限を持つユーザーとロールを作成できます。新しいユーザーまたはロールには、各データベースオブジェクトに必要な権限を選択的に付与する必要があります。これはエンドユーザーに多くの力を与えますが、それと同時に、正しい許可を持つユーザーとロールを作成するプロセスを潜在的に複雑にしています。 PostgreSQL では、データベースユーザーに直接権限を付与することができます。ただし、グッドプラクティスとして、アプリケーションとアクセスの要件に基づいて、特定の権限のセットを持つ複数のロールを作成することをおすすめします。次に、各ユーザーに適切な役割を割り当てます。ロールは、データベースオブジェクトにアクセスするための最小権限モデルを強制するために使用するべきです。Amazon RDS および Aurora PostgreSQL インスタンスの作成中に作られたマスターユーザーは、他のユーザー、ロール、およびデータベースの作成などのデータベース管理タスクにのみ使用する必要があります。マスターユーザーはアプリケーションによって使用されるべきではありません。 PostgreSQL できめ細かいアクセスコントロールを設定するための推奨アプローチは次のとおりです: マスターユーザーを使用して、readonly や readwrite などのアプリケーションまたはユースケースごとにロールを作成します。 これらのロールがさまざまなデータベースオブジェクトにアクセスできるように権限を追加します。例えば、readonly ロールは SELECT クエリのみを実行できます。 機能にとって最低限必要な権限をロールに付与します。 app_user や reporting_user のように、アプリケーションごとまたは個別の機能ごとに新しいユーザーを作成します。 適切なロールをこれらのユーザーに割り当てて、ロールと同じ権限をすばやく付与します。例えば、readwrite ロールを app_user に付与し、readonly ロールを reporting_user に付与します。 […]

Read More

2018 年に最もよく読まれた AWS データベースブログ

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

Read More

Oracle から PostgreSQL へ移行する際に、よく直面する課題を解決する方法

企業は年々データが急激に増加するのを目の当たりにしています。データベースとハードウェアインフラストラクチャをスケーリングし続けることは、ますます困難になっています。ワークロードが非リレーショナルデータストアに適していない場合に、基盤となるインフラストラクチャの管理に膨大な費用を費やすことなく、スケーリングの課題をどのように克服したらいいでしょうか? Amazon RDS for PostgreSQL と Amazon Aurora with PostgreSQL により、コスト効率の高い方法で PostgreSQL クラウドのデプロイを簡単にセットアップ、運用、拡張することができます。昨年、私たちは (数百 GB から数 TB に及ぶ) 100 を超える Oracle データベースを Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL に移行しました。 この記事では、移行中に持ち上がった最も一般的な問題のいくつかについて説明します。皆さんは AWS Database Migration Service (AWS DMS) を使用して、あるデータベースから別のデータベースにデータを移動させた経験があることでしょう。私も AWS Schema Conversion Tool (AWS SCT) をかなり使い込みました。手始めに、データ抽出プロセスで直面する可能性のある問題を取り上げます。次に、データの移行中に起こる問題について取り上げます。最後に、移行後に PostgreSQL で観察するパフォーマンスの問題について説明します。 抽出フェーズの問題 このフェーズで一般的に直面する問題は、大きなテーブルのデータ抽出が遅くなり、ソース DB で ORA-01555 エラー (スナップショットが古すぎます) […]

Read More

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するベストプラクティス: 移行プロセスとインフラストラクチャに関する考慮事項

AWS クラウドで Oracle から PostgreSQL に移行するプロセスは何段階もあって複雑になりがちです。評価ステージから切り替えステージまで、さまざまなテクノロジーとスキルが必要になります。このブログシリーズでは、ソースの Oracle データベースとターゲットの PostgreSQL サービス、そして AWS Database Migration (AWS DMS) サービスについて、その環境と構成の設定方法をお伝えしています。特に焦点を当てているのが、ソースおよびターゲットデータベースのインフラストラクチャと設定、そして開発からテスト、本稼働、ステージングデータベースまでの各環境の移行に使用するツールと構成です。まずは、Oracle から、PostgreSQL との互換性がある Amazon RDS for PostgreSQL または Amazon Aurora ベースのデータベースへのデータ移行から始めることにします。 環境はそれぞれ異なりますが、機能は共通です。このシリーズのブログ記事では、各コンポーネントについて、データベースを移行する際に考慮する概要情報をお伝えするにとどめています。アプリケーションのコンポーネントや各種のシナリオについて、込み入った複雑な点までは取り上げていません。利用状況に応じて大きく変わるからです。細かい点まで深く把握する必要がある場合は、AWS Database ブログの記事 Database Migration—What Do You Need to Know Before You Start? をお読みください。 このシリーズには 3 つのブログ記事があり、それぞれで移行の 3 段階を扱っています。 ステージ 1: 移行プロセスとインフラストラクチャに関する考慮事項。この記事では、ソースサーバーのインフラストラクチャ設定について説明しています。移行プロセスの概要レベルについても触れており、Oracle データベースとクライアントハードウェアおよびオペレーティングシステムに適宜アクセスする必要があります。 ステージ 2: Oracle および AWS DMS […]

Read More