Amazon Web Services ブログ

Category: Amazon Aurora*

Amazon Aurora (MySQL)がR4インスタンスをサポート – 最大書き込みスループットが2倍に-

本日より、Amazon Aurora (MySQL)でR4インスタンスファミリーがご利用頂けるようになりました。R4インスタンスファミリーは新世代のメモリ最適化インスタンスでR3インスタンスファミリーよりも大きなL3キャッシュや高速なメモリを搭載することで性能の向上を行えます。 R4インスタンスファミリー内で最大のR4.16xlargeでは、64コア ・488GiBメモリを搭載しています。Amazon Aurora (MySQL)では、R4.16xlargeインスタンスをご利用頂くことで、R3.8xlargeインスタンスと比較して倍の最大200,000 writes/second の書き込み性能を発揮出来ます。 R4インスタンスファミリーはAmazon Aurora (MySQL) version 1.15からご利用頂けます。R4インスタンスはAmazon Aurora (MySQL)がご利用頂ける全てのリージョンでサポートしています。価格に関する詳細情報はこちらをご覧下さい。ハイエンドの商用データベースの速度と可用性をオープンソースデータベースのシンプルさとコスト効率でご利用頂ける、Amazon Aurora MySQL/PostgreSQLついてはこちらをご覧下さい。 翻訳は星野が担当しました。(原文はこちら)

Read More

今すぐご利用可能 – Amazon Aurora with PostgreSQL Compatibility

昨年後半、Amazon Aurora に PostgreSQL 互換のエンジンを追加する計画をお話しました。このアナウンスのすぐ後に、プライベートベータを開始し、今年の前半にはオープンプレビューを開始しました。このベータとプレビューの期間、非常に素晴らしい数多くのフィードバックをいただき、このサービスがお客様のニーズを満たし、期待値を超えることが確かなものになるように、できる限りのことをしました! 一般利用可能に 本日、Amazon Aurora with PostgreSQL Compatibility が一般利用可能となり、4つのリージョンで利用できるようになったことをお伝えします(その他のリージョンは今後対応していきます)。本サービスは、PostgreSQL 9.6.3 と互換性があり、そのストレージは、64 TB まで自動的にスケールし、そのバックエンドで 6つのレプリカを持ち、性能と可用性を高めています。 Amazon Aurora with MySQL Compatibility のように、このエディションはフルマネージドで、簡単にセットアップし、利用できます。性能の観点ではお客様自身で運用していた PostgreSQL と比較して、最大3倍のスループットを期待することができます(我々がどのようにこれを実現したかについては、Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases をご確認ください)。 新たにアップデートされた RDS Console から PostgreSQL と互換性のある Amazon Aurora インスタンスを起動することができます。まず、Amazon Aurora をエンジンとして選択し、PostgreSQL-Compatible をエディションとして選択し、[Next] をクリックします。 そして、インスタンスクラス、シングル(開発、テスト環境向き)/Multi-AZ(本番環境向き) デプロイメントの選択を行い、インスタンス名、管理者パスワードを設定し、[Next]をクリックします。 インスタンスクラスは、6つのモデルの中から選択可能です(2 から 64 のvCPUと 15.25 から 488 […]

Read More

Sign up Today – Amazon Aurora with PostgreSQL Compatibility のプレビュー

昨年、Amazon Aurora に PostgreSQL 互換のエンジンをリリースするとアナウンスしました。その際、プライベートプレビューのサインアップを紹介し、申し込んでいただくようご案内しました。 そのリクエストの反応は非常に大きいものでした!お客様は既に Amazon Aurora が高い可用性、堅牢性を提供することを理解し、ご自身の PostgreSQL 9.6 アプリケーションを AWS クラウドで動かすのを楽しみにされていました。 Opening up the Preview 本日、興味をお持ちのすべてのお客様に Amazon Aurora with PostgreSQL Compatibility の プレビューを開放し、こちらからサインアップ可能となります。プレビューは、米国東部(バージニア北部)リージョンで実施され、従来の環境で運用されていたPostgreSQL に比べて、2-3倍の性能を提供します。このプレビューでは、高速で低レイテンシなリードレプリカをすばやく簡単に作成することも可能です。 Amazon RDS Performance Insights もPreview にてご利用可能です 本プレビューには、Amazon RDS Performance Insights も含まれます。このツールを利用することで、各クエリの詳細を含む細かいレベルでデータベース性能を確認することができます。Performance Insight ダッシュボードを通して、データベースの負荷を可視化し、SQL, waits, users, hostsという観点でフィルタリングできます: — Jeff; 原文: Sign up Today – Preview of Amazon Aurora with […]

Read More

Amazon Aurora: Fast DDLの詳細

Anurag GuptaはAmazon Auroraを含む彼がデザインに参加した、いくつかのAWSデータベースサービスに携わっています。 Under the Hoodシリーズでは、Auroraを支える技術や設計について説明します。 Amazon Auroraはオープンソースデータベースのシンプルさとコスト効率とハイエンドなコマーシャルデータベースの可用性と性能を兼ね備えたMySQL互換のデータベースです。この投稿では、Amazon Auroraが一般的な、完了までMySQLでは数時間かかるようなDDL文をほぼ即座に実行出来る仕組みを見ていこうと思います。   Fast DDLとは?なぜ考慮するのか アプリケーションを変更すると、それに付随するデータベースのスキーマを変更する必要があるケースがあります。クエリのワークロードが変わると、インデックスの追加や削除を行う必要があります。データのフォーマットが変更になると、既存のカラムのデータタイプを変更する必要があります。そして、このような変更は頻繁に起こりえます。Ruby on Railsアプリケーションをサポートする一部のDBAは、週に数十回スキーマを変更すると話しています。 多くのMySQLのDBAはご存知のように、このようなスキーマの変更はプロダクションシステムの中断が発生する可能性があります。変更に時間がかかるからです。場合によっては、完了まで数時間から数日かかることもあります。システムのリソースも奪われるため、アプリケーションのスループットも低下します。また、長時間のオペレーションは長時間のクラッシュリカバリが発生する可能性があります。DDL操作の一部は書き込みロックが必要なため、アプリケーションの一部が使用できなくなります。加えて一時的なスペースを多く必要とする可能性があり、小規模のインスタンスではディスクが不足する可能性もあります。 私たちはこのような点を取り除けるように改善を行っており、良く見る一般的なDDL操作(nullableカラムをテーブルの最後に追加)から改善を始めました。   なぜ既存の方法では問題が起こるのか? MySQLがどの様にnullableカラムをテーブルの最後に追加する実装になっているか見ていきましょう。 MySQLは以下のような処理を行っています: データベースはトランザクションのprepareフェーズでオリジナルテーブルに対して排他ロックを取得します 変更後のスキーマで新しい空のテーブルを作成します 1行ずつコピーを行ない、インデックスをその後作成する。同時に実行されたデータ操作(DML)文は、一時ファイルに記録されます 再度、排他ロックを取得し一時ファイルから新しく作成したテーブルへDML文を適用します。適用すべき操作が多くある場合、この処理に時間を要します オリジナルテーブルをdropし、テーブルをリネームします これらの処理には多くのロックが必要になり、データのコピーやインデックスの作成にオーバヘッドが必要になります。そして、I/Oが多く発生し、一時領域も消費します。   もっと良い方法はないのでしょうか? これについてはないと思うかもしれません。各行のデータ形式は変更する必要があります。しかし、この変更をテーブル上で実行されている他のDML(および関連するI/O)操作の上にのせることで、多くのことが実行できます。 完全なアプローチは、ブログポストではやや複雑すぎるので、ここでは簡単に説明します。 Auroraでは、DDLをユーザが実行すると データベースがINFORMATION_SCHEMAのシステムテーブルを新しいスキーマで更新します。加えて、各操作に対してタイムスタンプを付与し変更をリードレプリカに伝搬します。古いスキーマ情報は新しいシステムテーブル(Schema Version Table)内に格納されます 同期的に行う操作はこれだけで完了です。 そして、その後のDML文は、影響のうけるデータページがスキーマの変更を待っている状態か監視します。この操作は、各ページのlog sequence number (LSN)タイムスタンプとスキーマ変更のLSNタイムスタンプを比べるだけで簡単に行なえます。必要に応じて、DML文を適用する前に新しいスキーマにページを更新します。この操作は、redo-undoレコードページの更新と同じ更新プロセスで実行されます。そして、I/Oはユーザの実行するクエリと同様に扱います。 DML操作では、ページ分割が発生する可能性があるため、ページの変更に注意する必要があります。変更はAuroraのレプリカノードでも同様に扱う必要があります。そして、リードレプリカではどのデータへの変更も許可されていません。SELECT文のために、MySQLに戻されるメモリ上のバッファ内のイメージ変更します。この方法では、ストレージ内で新旧のスキーマが混在していたとしても常に最新のスキーマを参照出来ます。 もし、皆さんがAuroraがどのようにストレージからの読み込みとログの適用を行っているかご存知の場合、このアプローチが似ていると感じると思います。しかし、このアプローチではredo logのセグメントではなく、変更を記録するためにテーブルを使用します。 パフォーマンス比較は以下のようになっています。Auroraは Schema Version Tableを変更するために一定の時間で処理が完了しているのがおわかりになると思います。しかし、MySQLではテーブルサイズにほぼ比例して線形に処理時間が増加しています。 明らかに私達が改善すべき多くのDDL文があります。しかし、殆どの物は同様のアプローチで対処可能と考えています。 このことは重要です。たとえデータベースが通常の可用性で稼働していても、これらの長い操作ではアプリケーションへ影響が発生します。それらを並列、バックグラウンド、非同期処理に移すことで違いが出てきます。 質問やフィードバックはありますか?aurora-pm@amazon.comへ是非お寄せ下さい。皆さんの考えや提案を私たちは非常に大切にしています。 注: こちらの機能は2017年4月6日現在Lab modeにてご提供しております。 翻訳は星野が担当しました。原文はこちら。

Read More

Amazon Auroraアップデート: クロスリージョン・クロスアカウントサポートの拡張、T2.Small DBインスタンス、リージョンの追加

Amazon Auroraの最近のアップデートを振り返ってみたいと思います。Amazon AuroraはMySQL互換のハイパフォーマンスなデータベースです(間もなくPostgreSQL互換のAuroraもリリース予定です)。Amazon Auroraの紹介は、【AWS発表】Amazon Auroraをご利用頂けるようになりました!や【AWS発表】Amazon Aurora – Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!!をご覧ください。 最近Auroraへ追加された機能は以下のとおりです クロスリージョンスナップショットコピー 暗号化されたデータベースのクロスリージョンレプリケーション 暗号化されたスナップショットのアカウント間の共有 US West (Northern California)リージョンのサポート T2.smallインスタンスサポート   クロスリージョンスナップショットコピー Amazon Auroraのスナップショット(自動・手動取得に関わらず)リージョン間でコピー出来るようになりました。スナップショットを選択し、Snapshot ActionsからCopy Snapshotを選択します。その後、リージョンを選択後、新しいスナップショットの名前を入力します。 この操作の中で、暗号化済みスナップショットも選択可能です。詳細はドキュメントをご覧ください。   暗号化されたデータベースのクロスリージョンレプリケーション Amazon Aurora DBを作成する際に暗号化オプションを設定出可能です。 数クリックで他のリージョンにリードレプリカを作成することが出来るようになりました。この機能を利用することで、マルチリージョン、ハイアベイラビリティなシステムが構築可能になりますし、ユーザに近い位置にデータを移動することも可能です。クロスリージョンリードレプリカを作成するには、既存のDBインスタンスを選択し、メニューからCreate Cross Region Read Replicaを選択するだけです。 その後、Network & Securityからリージョンを選択し、Createをクリックします。 レプリケーション先のリージョンには必ず2つ以上のアベイラビリティゾーンを含んだDB Subnet Groupが必要です。 このパワフルな新機能について詳細は、ドキュメントをご覧ください。   暗号化されたスナップショットのアカウント間の共有 Amazon Aurora DBインスタンスを作成する際に、定期的に自動でスナップショットを行う設定が可能です。この他にも、数クリックで任意のタイミングでスナップショットを作成することも可能です。 DBインスタンスが暗号化されている場合はスナップショットも暗号化されます。 AWS間で暗号化されたスナップショットを共有出来るようになりました。この機能を使うためには、DBインスタンスはdefault RDS keyではないマスターキーで暗号化されている必要があります。まず、スナップショットを選択し、Snapshot ActionsメニューからShare Snapshotを選択します。 そして、共有先のAWS Account […]

Read More

Amazon Aurora: 暗号化されたスナップショット・データベースに対する新機能

本日Amazon Auroraの新機能を2つリリース致しました。 暗号化済みデータベースのクロスリージョンサポート 暗号化済みのデータベースでAWSリージョンをまたいだレプリケーションがサポートされました。クロスリージョンレプリケーションを利用することで、ユーザに近い場所でリードオペレーションを実行することが可能になったり、ディザスターリカバリー環境を簡単に構築出来ます。また、リージョンをまたいだデータベースの移行も容易に行なえます。 また、暗号化されたスナップショットをAWSリージョン間でコピー可能になりました。開発チームとテストチームが様々な地域に分散していたとしても、本番データベースの最新のコピーを安全に共有することによって、グローバルな開発プロセスを構築できます。また、遠隔地にスナップショットを安全に保管することで、ディザスターリカバリー戦略を強化することも可能です。 詳細は、クロスリージョンレプリケーションとクロスリージョンスナップショットコピーのドキュメントをご覧ください。   AWSアカウント間で暗号化済みスナップショット共有をサポート AWSアカウント間で暗号化済みスナップショットの共有が可能になりました。暗号化キーを共有しているアカウントを分離するためにAuroraのセキュリティモデルを拡張出来ます。他のアカウントの所有者は、スナップショットをコピーしたり、スナップショットからデータベースインスタンスを復元することができます。 詳細なドキュメントはこちらをご覧ください。 Amazon Auroraは、フルマネージド、高可用性、コストパフォーマンスのよいリレーショナルデータベースです。MySQLと互換性があるためアプリケーションコードの変更なしに移行が行なえます。また、こちらのツールを利用することでダウンタイムを最小限に移行を行うことも可能です。 翻訳は星野が担当しました。原文は、Amazon Aurora Announces Encryption Support for Globally Distributed Database Deployments, Amazon Aurora Supports Cross-Account Encrypted Snapshot Sharing            

Read More

シャーディングされたシステムをAuroraに集約してリソースの消費を削減

リレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと2つの手法が上げられます。一般的にスケールアップの方が簡単に行えます(単純にスペックのいいマシンを購入するなど)。一方スケールアウトは、それぞれ独立したホストで稼働している複数のサーバへ、データベースをシャーディングする必要があり作業が煩雑になります。 難しさにも関わらずスケールアウトとが最近のトレンドとなってきています。コモディティハードウェアとシステムリソースへの要求の増加に伴いワークロードを効率的にシャーディングする必要が出てきました。シャーディングされたシステムの1つの欠点として管理コストがあげられます。もし4つのシャードを持っているとすると、4つのデータベースを管理する必要があります。しかし、たとえそうだとしてもスケールアウトはスケールアップよりコスト効率がいい場面が多かったのです。特にAmazon RDSの様なマネージドデータベースの登場によりリレーショナルデータベースの管理を軽減することが出来るようになったのがその1つの要因です。 しかし、なぜ過去形なのでしょうか? Amazon Auroraの登場によりスケールアップという選択肢が戻ってきたのです。Amazon Auroraは非常にスケールし、MySQL互換のマネージドデータベースサービスです。Auroraは2 vCPU/4 GiBメモリというスペックのインスタンスから、32 vCPU/244 GiBメモリ搭載のインスタンスまでを提供しています。Amazon Auroraは需要に応じてストレージが10 GBから64 TBまで自動的に増加します。また、将来のリードキャパシティの増加に備えて15インスタンスまで低遅延のリードレプリカを3つのアベイラビリティーゾーンに配置することが可能です。この構成の優れている点は、ストレージがリードレプリカ間でシャーディングされている点です。 シャーディングされたシステムを1つのAuroraインスタンスに集約、もしくは少数のシャードに集約しAuroraで稼働させることで多くのコストを節約する事が可能です。これがこのブログポストでお話したいことの全てです。 シャーディングされたシステムをAuroraに集約するために – まずはじめに – 多くのシャーディングされたシステムは標準的な方法で行うことが可能です。データはカスタマーIDなどの特定のキーを元に分割されており、何かしらマッピングを行う機能を用いてシャードに分割されています。この方法には様々な種類があり、1例として参照用のデータを別のシステムか1つのシャードに格納したり、全てのシャードに参照用のデータを配置するなどがあります。どのようにデータを分割しても、シャーディングの複雑さは通常、アプリケーションレイヤーにあり、シャードの統合は比較的容易に行えます。 多分皆さんは今、”利点はわかった。ではどうやってAuroraにデータを移行するのか”という疑問をお持ちかと思います。今回の例では、MySQLを利用して4つのシャードを持つシステムを利用していると仮定したいと思います。また、各シャードは他のシャードが持っているデータを持っていないものとします。また1つのシャードが参照用のデータを持っている前提とします。現在の構成は以下の図の様な構成になっていると思います。mapは各シャードへのアプリケーショントラフィックを表しています。 MySQLを運用しているため、Aurora documentationに記載されている方法を利用を利用可能です。簡単に移行を行うために、まずはじめに参照データのみが格納されているインスタンス1を移行します。しかし、どのシャードを最初に移行するかはそれほど重要ではありません。 移行が完了すると、マッピング機能はインスタンス1ではなくAuroraインスタンスを指します。システムは次の図のようになります。 残りのデータを移行する この時点で、Auroraが特定のワークロードをどれくらいうまく処理しているか評価し、必要な調整を行う必要があります。設定に問題がなくなれば、他のデータを移行する準備は完了です。では、シャード2をAuroraインスタンスに移行しましょう。しかし、どうやって?   AWS Database Migration Service (AWS DMS)を是非ご活用下さい!AWS DMSはこのようなマイグレーションにも対応するように作られました。シャード2からAuroraインスタンスへデータをコピーするためにDMSをご利用になれます。更に、シャード2にとランアクションを実行しながらこれらの作業が可能です。DMSは初期データのロードが完了すると、それらのトランザクションデータをシャード2から収集しAuroraインスタンスに適用します。DMSは継続的にシャード2からAuroraインスタンスへデータを移行し、シャード2の代わりにAuroraインスタンスの利用を開始させるまで同期させます。シャード2からAuroraインスタンスへ切り替える準備が出来たら、シャード2へのトランザクションを停止し、DMSが最後のトランザクションをAuroraインスタンスへ適用するまで待ち、mapの設定を、シャード2に向いていたトラフィックを直接Auroraインスタンスへ向くように変更します。設定が完了すると、システムは以下のような状態になります。 この時点から、Database Migration Serviceを残り2つのシャードをAuroraインスタンスへ移行するために利用出来ます。最終的にシステムは以下の様になります。   複雑なシャードの扱い方 これでシャーディングされたシステムが1つのAuroraインスタンスへマイグレーションが完了し、コストを削減することが出来ました!しかし、MySQLを利用し、クリーンなシャードを利用しているとう仮定で話をすすめてきました。もしこれらの仮定にそぐわない場合はどうでしょうか? それでは、シャードがクリーンな状態でない場合を見ていきましょう。例えば、システムが最初に2つのシャードで構成されていたとします。ある時点で、その2つのシャードを4つのシャードに分割したとします。 リシャードィングプロセスの一環として、シャード1と2のコピーを作成してシャード3と4を作成し、マッピング機能を更新しました。 結果は次のようになります。 この図は状況が複雑であるように見えます。 理想的には、このようなリシャードィングの際に、シャードに関係のないデータ、つまりグレーアウトされたデータをパージします。 しかし、必ずしも必要というわけではないし、時には難しいこともあるので、データをそのままにしておく事があります。 この方法では使用されていない冗長なデータを保持する”汚れた”シャードが発生します。 これらのシャードを統合しようとすると、アクティブなデータの行が、削除すべき重複した行と衝突する問題が発生します。 何をすべきか? シャードの統合を行う前に、利用していない行を削除することができます。 しかし、特にマッピング関数がID値のハッシュ(一般的な方法の1つ)で構成されている場合、利用していない行を特定するのは難しいかもしれません。 諦めないで下さい! 別のオプションがあるかもしれません。 各シャード内のデータが1つのデータベースに含まれている場合は、DMSを使用して、システムの各シャードをAuroraインスタンス内の単一のMySQLデータベースに統合できます。 次に、既存のマッピング・スキームを使用して、Auroraインスタンス内の適切なデータベースにトランザクションを転送できます。 […]

Read More

RDS MySQL DBインスタンスからAmazon Aurora Read Replicaを作成可能になりました

24時間365日稼働しているアプリケーションが利用しているデータベースエンジンを他のデータベースエンジンに移行するにはいくつかの方法を使う必要があると思います。データベースをオフラインにせずに移行する良い方法として、レプリケーションを利用する方法があります。 本日、Amazon RDS DB for MySQLインスタンスを Amazon AuroraにAurora Read Replicaを作成して移行する機能をリリースしました。マイグレーションは、まず既存のDBスナップショットを作成し、そこからAurora Read Replicaを作成します。レプリカのセットアップが完了後、ソースデータベースとのレプリケーションの設定を行い最新のデータをキャッチアップします。レプリケーションラグが0になればレプリケーションが完了した状態です。この状態になった後に、 Aurora Read Replicaを独立したAurora DB clusterとして利用可能で、アプリケーションの設定を変更しAurora DB clusterに接続します。 マイグレーションはテラバイトあたり数時間かかります。また、6TBまでのMySQL DBインスタンスに対応しています。InnoDBテーブルのレプリケーションはMyISAMテーブルのレプリケーションよりもやや高速で、圧縮されていないテーブルの利点も受けられます。 RDS DBインスタンスをマイグレーションするためには、 AWS Management ConsoleからRDSのコンソールを選択し、Instance Actionsを選択します。その後、Create Aurora Read Replicaを選択するだけです: そして、データベースインスタンスの情報やオプションを入力し、Create Read Replicaをクリックします: コンソール上でマイグレーションの進捗状況を閲覧出来ます: マイグレーション完了後、Aurora Read Replicaでレプリカラグが0になるのを待ちます(SHOW SLAVE STATUSコマンドをレプリカで実行し、“Seconds behind master”を監視します)。その後、ソースのMySQL DBインスタンスへの新しいトランザクションを停止し、Aurora Read ReplicaをDBクラスタに昇格させます: 新しいクラスタが利用可能になるまで待機します(通常は1分程度): 最後に、アプリケーションの設定をクラスタのread/writeエンドポイントを利用するように設定し完了です! — Jeff; (翻訳は星野が担当しました。原文はこちら)

Read More

Amazon Aurora Clusterに監査機能を追加

re:InventでMySQLデータベースと互換性があり、コマーシャルデータベースの性能と可用性、オープンソースデータベースのコストパーフォーマンスの両面をそなえた、Amazon Auroraの新機能を発表しました。 今日、advanced auditing機能が全てのお客様にご利用頂けるようになったことを発表致します。 advanced auditingとは Auditingとは特定のイベントを収集して手動もしくは他のアプリケーションで分析出来るように提供する機能を指します。これらのログはコンプライアンス規定やガバナンスのベースになる情報として利用可能です。advanced auditingの例には、ログ分析、ユーザーアクションの監査(過去のイベントおよび、ニアリアルタイムの脅威検出など)、セキュリティ関連のイベントに設定されたアラームのが含まれます。 Auroraのadvanced auditing機能は、データベースのパフォーマンスに与える影響を最小限に抑えながら、これらの機能を提供するように設計されています。 advanced auditingを利用するには まずはじめに、advanced auditingを有効にし、audit logを参照します。 advanced auditingの有効化 DBクラスタパラメータグループにあるパラメータを設定することでadvanced auditingの有効化や設定を行うことができます。これらのパラメータの変更がDBクラスタの再起動は必要ありません。また、動作は Aurora DB instance parametersと同様です。 機能を有効/無効化するために server_audit_loggingパラメータを利用します。server_audit_eventsパラメータでどのイベントをログに記録するか設定します。 server_audit_excl_usersとserver_audit_incl_usersパラメータでどのユーザを監査対象にするか設定可能です: server_audit_excl_usersとserver_audit_incl_usersが未指定の場合(デフォルト値)は全てのユーザが記録されます server_audit_incl_usersにユーザを設定し、server_audit_excl_usersを指定しない場合、server_audit_incl_usersに指定したユーザのみ記録されます server_audit_excl_usersにユーザを設定し、server_audit_incl_usersを指定しない場合、server_audit_excl_usersに指定したユーザ以外が記録の対象になります server_audit_excl_usersとserver_audit_incl_usersに同一のユーザを設定した場合は、server_audit_incl_usersの優先度が高いため記録の対象になります advanced auditingのパラメータの詳細を以下でご説明します server_audit_logging 監査ログの有効/無効化を指定します。標準ではOFFになっているので、ONに指定することで有効になります Scope: Global Dynamic: Yes Data type: Boolean Default value: OFF (disabled) server_audit_events イベントのリストをカンマで区切って指定します。リスト中のエレメント間にスペースは入れなように気をつけて下さい Scope: Global Dynamic: Yes Data type: String Default value: Empty […]

Read More

Amazon Auroraアップデート – 空間インデックス・ゼロダウンタイムパッチ

AWSの様々なサービスがリリースされてりますが、Amazon Auroraは現在もAWSサービスの中で最も速く成長しているサービスです!お客様には速度、パフォーマンスや可用性を評価頂いています。MySQL互換のAuroraを多く利用いただいていますが、今後リリースされるPostgreSQL互換のAuroraへも期待していただいています(詳細や最近Auroraに追加された機能はAmazon Aurora アップデート – PostgreSQL 互換のエンジンをご覧ください)。 本日、AWS re:Inventでアナウンスをした、空間インデックスとゼロダウンタイムパッチの2つの機能をリリースしました。 空間インデックス Amazon Auroraは今までも地点やエリアを表すためにGEOMETRY型をご利用頂けました。この型を使ってカラムを作成し、ST_Contains, ST_CrossesやST_Distance(更に他にも)といった機能をspatial queryを実行するためにお使い頂けました。これらのクエリはパワフルですが、大きなデータセットに対してスケールするには不十分な点や制限がありました。 Auroraを利用して、ラージスケールな位置情報を使うアプリケーションを作成していただくために、空間データに対してとても効率的なインデックスをお使い頂けるようになりました。Auroraは dimensionally ordered space-filling curve (次元的に整列した空間充填曲線)を利用して、スケールし、高速かつ正確に情報を取り出すことが出来ます。インデックスはb-treeを使い、MySQL5.7と比較して最大2倍のパフォーマンスです(詳細は、こちらのプレゼンテーションとAmazon Aurora Deep Diveのこちらの箇所をご覧ください)。 この機能を現在ご利用頂くためには、Aurora Lab Modeを有効にして頂く必要があります。機能を有効にした後は、既存のテーブルや新規に作成するテーブルにspatial indexを設定頂けます(詳細はこちらをご覧ください)。 ゼロダウンタイムパッチ 今日のような24×7の世界で、データベースへのパッチ適用やアップデートでデータベースをオフラインにする良い時間はありません。しかし、高可用性を維持するために、read replicaを利用して昇格させる方法が利用されてきました。 私達の、新しいゼロダウンタイムパッチ機能により、Auroraインスタンスへのパッチ適用をダウンタイム無しで、可用性にも影響を及ぼさずオンラインで実行出来るようになりました。この機能は、現在の最新バージョン(1.10)が適用されたAuroraインスタンスで、ベストエフォートで機能します。シングルノードクラスタとマルチノードクラスタのWriterインスタンス双方で機能しますが、バイナリログが有効になっている場合は無効になります。 このパッチは、既に開かれているSSLコネクション、アクティブなロック、トランザクションの完了やテンポラリテーブルの削除を待ちます。パッチ適用可能なウインドウが出来た場合、ゼロダウンタイムパッチとして適用します。アプリケーションセッションは保持されたまま、パッチが適用される間データベースエンジンがリスタートします。この間瞬間的(5秒程度)なスループット低下が発生します。もし、ゼロダウンタイムパッチで適用出来るウインドウがなかった場合、通常のパッチ適用プロセスが実行されます。 さらに詳細にこの機能がどのように動作するかや実装方法については、Amazon Aurora Deep Dive videoのこちらの箇所をご覧ください。 本日からご利用いただけます これらの新機能が本日からご利用頂けます! その他の機能改善やBug fixはこちらのforumをご覧ください。 — Jeff; (翻訳は星野が担当しました。原文はこちら)

Read More