Amazon Web Services ブログ

Category: Amazon Aurora

Amazon Aurora PostgreSQL でのクエリ計画管理のユースケース

このブログの投稿は一連の投稿の 2 回目です。前回のブログ記事では、SQL ステートメントの実行計画に回帰を引き起こす可能性があるその他の変更の中で、安定かつ一貫したデータベースパフォーマンスの必要性について説明しました。また、PostgreSQL と互換性のある Amazon Aurora のクエリ計画管理 (QPM) が、計画安定性と計画適応性の問題を克服できるようにする方法も述べています。 この記事では、引き続き Aurora PostgreSQL QPM の機能について説明します。特に、これらの機能によって、さまざまな高度なユースケースに対して計画安定性と適応性を実現する方法についてお話します。 ユースケース #1: QPM 手動取得による計画安定性と適応性の支援 最初のユースケースでは、QPM が計画安定性を確保する方法について例を挙げて説明します。次に、前回の記事 Aurora PostgreSQL クエリ計画管理の概要で説明した変更を行います。QPM を使用しない場合は、これらの変更により計画の回帰が生じる可能性があります。 ほとんどの場合、自動計画取り込みを使用するように QPM を設定して、2 回以上実行されるすべてのステートメントを取得することもできます。ただし、手動で指定した特定のステートメントセットの計画を取得することもできます。そのためには、デフォルトに capture_plan_baselines = off を設定します。セッションレベルでは、capture_plan_baselines = manual を設定します。設定の仕方については後で説明します。 手動計画取り込みを有効にして、目的の SQL ステートメントの実行計画を手動で取得するように QPM に指示します。 pg105db=> SET apg_plan_mgmt.capture_plan_baselines = manual; SET QPM がクエリ計画を取得できるように、クエリ説明計画を実行します (説明計画の以下の出力は、簡潔にするために省略されています)。 pg105db=> explain (hashes true) SELECT […]

Read More

Aurora PostgreSQL クエリ計画管理の概要

すべての AWS サービスと同様に、Amazon Aurora PostgreSQL のロードマップは、主にお客様のご意見と製品強化のご要望によって推進されます。Oracle と Microsoft SQL Server から Amazon Aurora にデータベースを移行した、複数の企業お客様からいただいたフィードバックは、2 つの点を示唆しています。重要なアプリケーションのデータベースワークロードを実行する企業は、最適なデータベースパフォーマンスを必要とします。また、企業には Aurora PostgreSQL と互換性のあるデータベースでさまざまなシステム変更を行っても、安定かつ一貫性を保つパフォーマンスが必要です。 PostgreSQL データベースのパフォーマンスが変動する主な原因の 1 つはチェックポイントプロセスにあります。多くの場合、パフォーマンスと回復性の間のトレードオフのことです。Aurora PostgreSQL では、データベースのチェックポイントを排除することでこの問題に対処してきました。ログ記録とストレージレイヤーを切り離すために、ログベースのストレージサブシステムを実装します。応答時間が変動するもう 1 つの主な原因は、クエリ計画の不安定性によるものです。クエリ実行計画を予期せずに変更する、さまざまな要因があります。以下に例を挙げます。 オプティマイザ統計の変更 (手動または自動) クエリ計画設定のパラメータに対する変更 新しいインデックスの追加など、スキーマに対する変更 クエリで使用されるバインド変数に対する変更 PostgreSQL データベースバージョンへのマイナーバージョンまたはメジャーバージョンのアップグレード。PostgreSQL 9.6.x から 10.x など クエリ計画管理 Aurora PostgreSQL クエリ計画管理 (QPM) 機能は、データベースユーザーが一連の管理 SQL ステートメントに対して安定かつ最適なパフォーマンスを維持できるようにすることで、計画不安定性の問題を解決します。QPM では主に 2 つの目的を果たすことができます。 計画安定性。システムに上記の変更が発生した場合、QPM は計画の回帰が生じないようにして、計画安定性を向上させます。 計画適応性。QPM は、新しい最小費用計画を自動的に検出し、新しい計画が使用されるときに制御し、その変更に適応します。 QPM の仕組み 以下のフローチャートは、QPM […]

Read More

[AWS Black Belt Online Seminar] Amazon Aurora MySQL 資料及び QA 公開

先日 (2019/4/24) 開催しました AWS Black Belt Online Seminar「Amazon Aurora MySQL」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190424 AWS Black Belt Online Seminar Amazon Aurora MySQL from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. Auroraでbinlogのユースケースは、どの様なことがありますか?(※今日のウェビナーを聞いて、リストアで使う必要性はないと感じたものです) A. Amazon Auroraでは標準ではバイナリログを利用しないレプリケーションやクラッシュリカバリを採用しているため、有効にするケースは少ないと考えております。利用用途としてはAmazon Auroraに移行する際に切り戻し用途で利用されるケースがございます。バイナリログが有効な状態ですとフェイルオーバーやクラッシュリカバリの時間が無効の状態よりも長くなる可能性があるため、有効にされる際は事前の検証を推薦しております。 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。 AWS Innovate オンラインカンファレンス ≫ 申込先 2019 年 4 月 8 日〜5 月 7 日期間中いつでもオンラインで視聴可能 AWS基礎、業種別事例、人材育成、認定対策講座などAWSが厳選した33セッションを一挙に公開 — AWS Black Belt Online Seminar […]

Read More

改元はどのように RDS で実行されている MySQL 互換エンジンに影響を与えるか

RDSもしあなたのソフトウェアやシステムが日本のお客様をサポートしており、さらにそのソフトウェアやシステムが元号を表示する必要がある場合、新しい元号を表示するように改修の必要があるかもしれません。新しい元号は、現在の天皇陛下が退位される 2019 年 5 月 1 日から有効になります。 このブログ記事では、かかる元号の変更(改元)にかかわる背景について説明し、その後、どのように改元の影響を調べるかを、私が RDS で実行される MySQL 互換のデータベースエンジンについて調査した際の方法を元に、詳しく解説します。またその調査の結果、RDS で実行される MySQL 互換のデータベースエンジンは改元の影響を受けない、という結果を得たことを報告します。 改元について 元号は、日本で、主に政府のシステムや公的な文書などを中心に、未だ広く使われています。そのようなシステムをサポートするために、いくつかのソフトウェアでは元号をサポートするための機能が実装されています。例えば、Windows では元号をレジストリに格納していたり、Oracle データベースは元号を表示するためのカレンダー・ファイルを持っていたり、glibc ライブラリの strftime()関数は元号を表示するための機能があり、日本語のロケール・ファイルには元号の情報が含まれていたりします。 来る 2019 年 4 月 30 日に、現在の天皇陛下が退位され、それにともない 2019 年 5 月 1 日から元号が変更されます(改元)。そのため、元号をサポートするソフトウェアは、新しい元号を表示できるように更新する必要があります。 新しい元号は2019 年 4 月 1 日に発表される予定となっており、ソフトウェアのアップデートを準備する時間は 1 ヶ月未満の短い期間しかありません。 条件の理解 基本的に、Linux ビルトインのソフトウェアのうち、元号の表示に対応しているものは glibc() ライブラリの strftime() 関数のみです。 strftime()は日付や時刻の表示フォーマットを変更するための関数で、元号を使用して日付を変更する機能を持ちます。日本語 (ja_JP) ロケールを使用しているシステムでフォーマット指定子 (format specification) として […]

Read More

Amazon Aurora MySQL 互換エディションでグローバルトランザクション ID (GTID) によるレプリケーションがサポートされるようになりました

Amazon Aurora MySQL 互換エディションは、ハイエンドな商用データベースの速さや信頼性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。また Amazon Aurora with MySQL compatibility は、標準の MySQL Community Edition に比べ最大 5 倍のスループットを実現します。 本ブログ記事では、オンプレミスまたは Amazon EC2 上でホストされている MySQL DB を、新たにリリースされた GTID べースのレプリケーション機能を使用する Aurora MySQL に移行するのに役立つガイダンスについて解説します。 GTID ベースのレプリケーションとは? グローバルトランザクション ID (GTID) とは、MySQL、または MySQL 互換エンジンを実行するデータベースサーバー上でコミットされた各トランザクションに作成され、関連付けられる固有の識別子です。この ID は元のサーバーと、さらにトランザクションの両方を個別に識別します。 フェイルオーバーやダウンタイム後、データベース管理者にとって最大の課題は、ひとつの変更もスキップされることなく、また、一切の競合が生成されることない方法でレプリケーションを復元することです。ワークロードが動的に、スケーラブルに、また複雑になるに従って、これらの再構成タスクもますます頻度が増えていきます。その結果として、バイナリログファイルの位置を特定するのに必要な管理的オーバーヘッドが増大し、それによって、復旧時間が長引きます。

Read More

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

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

Read More

Intuit 社の導入事例: オンプレミス MySQL から Amazon Aurora への移行の自動化

Intuit社はレガシーデータセンターを売却し、顧客向けアプリケーションである QuickBooks、TurboTax、および Mint を AWS に移動させており、今後数年の間には完全に移行させる予定です。このブログ記事では、彼らがオンプレミスMySQLの移行先として、どのような基準で Amazon Aurora を選び、どのようにして最小限のダウンタイムで移行したのかについて共有されています。

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

Amazon Aurora PostgreSQL によるフェイルオーバー

レプリケーション、フェイルオーバー、レジリエンス、災害対策、バックアップ—従来の、または非クラウドベースのアーキテクチャでは、これらの一部またはすべてを実現するのはとても困難です。さらに、時にはかなりのリエンジニアリング作業が必要になることがあります。関係する実装やインフラストラクチャのコストが高いため、一部の企業では最も重要なアプリケーションのみが適切に保護されるようにアプリケーションを階層化せざるを得ません。 こうした懸念は、Amazon Aurora for PostgreSQL に移行すること軽減できます。AWS は、Oracle、MySQL、PostgreSQL、Aurora を含む (ただしこれらに限定されない) 幅広い種類のリレーショナルデータベースエンジンを提供しています。PostgreSQL の場合、AWS は Amazon EC2 インスタンスでの PostgreSQL、Amazon RDS for PostgreSQL、Amazon Aurora with PostgreSQL compatibility を含むさまざなバリエーションをサポートしています。適切なバージョンの PostgreSQL を選択するための多くの指標の中で、以下のいくつかが重要です。 高可用性 (HA) パフォーマンス 管理のしやすさ それでは、Amazon Aurora PostgreSQL がこうした基準をどのように満たしているかを掘り下げてみましょう。 高可用性: HA は、Aurora PostgreSQL のアーキテクチャに組み込まれており、3 つのアベイラビリティーゾーンにわたって 6 つのデータコピーが維持されています。つまり、アベイラビリティーゾーンごとに 2 つのコピーがあることになり、いずれかのアベイラビリティーゾーン全体がダウンしてもわずかな中断で済むことから可用性が向上します。さらに、データベースは Amazon S3 に継続的にバックアップされるため、S3 の高耐久性 (99.999999999) をバックアップで利用できます。Aurora PostgreSQL は、ポイントインタイムリカバリもサポートしています。 パフォーマンス: Amazon Aurora […]

Read More

SQL Server エージェントのジョブを AWS Step Functions に置き換える

Microsoft SQL Server から Amazon Aurora PostgreSQL への移行の場合に、SQL エージェントのジョブを簡単に移動できないことにお気づきかもしれません。Aurora PostgreSQL ではジョブエージェントツールがサポートされていません。この制限を克服するには、AWS Step Functions を使用して SQL エージェントのジョブを置き換えます。 このブログ記事では、ステップ関数を作成して、SQL ストアドプロシージャを実行する SQL エージェントのジョブを置き換える方法を示します。 ソリューションを実行するためのステップ このソリューションを実行するためのコードと AWS CloudFormation テンプレートは、この GitHub Amazon Repository にあります。 ソリューションを作成するために、CloudFormation テンプレートを使用して以下を準備します。 パブリックで利用可能なスナップショットからの SQL Server データベース用の Amazon RDS。 ステートマシン用の IAM ロール。 Step Functions アクティビティ。 Step Functions ステートマシン。 Step Functions ステートマシンを起動するための Amazon CloudWatch Events ルール。 CloudFormation テンプレートを使用して上記のリソースを準備した後に、以下の操作を実行します。 […]

Read More