Category: Database*


Redshiftアップデート:バックアップ不要表の指定、トランザクションのロック状況を出力する新しいビュー等

Redshiftに最近追加された新機能や、SASのRedshift対応強化についてアナウンスが出ていましたので、ご紹介します。

BACKUP NO オプションをCREATE TABLEで指定できるようになりました。名前の通り、この指定を付けた表はRedshiftの自動・手動SNAPSHOTでバックアップが取得されなくなります。Redshiftを活用する上で、一次的に中間データを置く表を作成することが良くあるのですが、これまではそのような一時表も自動SNAPSHOTの対象になっていました。このオプションでSNAPSHOT不要な表を指定することで、パフォーマンスの向上と、SNAPSHOTサイズの縮小が期待できます。

参照)BACKUP

MD5ハッシュの文字列を使ったCREATE USER/ALTER USERが利用可能になりました。クラスターバージョン1.0.1046以降で利用可能です。

通常CREATE USERを実行する際には、引数でパスワードを指定する必要があります。これをシェルスクリプトに書いて実行する場合を想定すると、そのファイルからパスワードが漏洩してしまうリスクがありました。今回の機能改善では、予めMD5ハッシュ化した文字列をCREATE USERのパスワードに指定する事が可能になりました。Redshiftは与えられたパスワードをMD5ハッシュ化して格納していますが、これをユーザが直接指定することが出来るようになったわけです。MD5ハッシュ化した文字は簡単にはパスワードに逆変換できないため、漏洩時のリスクを小さくすることが可能です(漏洩しても絶対大丈夫という意味ではありません)。

パスワードとユーザ名を連結した文字列をRedshiftのMD5関数に通すことで、必要なハッシュ化文字列が得られます。詳しくは以下のCREATE USERのマニュアルをご参照ください。PASSWORD引数の書き方の部分に例とともに解説があります。(※執筆時点では英語版にして確認する必要がありました)

参考)CREATE USER
新しいSVV_TRANSACTIONSビューが提供されました。このビューをクエリすることで今実行中のトランザクション一覧が得られます。granted列が’t’になっているトランザクションが、今ロックを保持している、つまり今実行されているSQLです。これが’f’の場合はロックを待っているSQLという事になります。このビューでロック競合で待たされているトランザクションを発見することが容易になります。

参考)SVV_TRANSACTIONS

SAS/ACCESSのRedshift対応が拡張され、自動的なプッシュダウン等がRedshiftに対して有効になりました。これまでもSASからRedshiftへ接続してデータ分析を行う事が可能でしたが、機能拡張され、 Implicit pass-through機能が有効になりました。これはSASへのクエリの一部をSQLに変換してRedshift側に移譲(プッシュダウン)し、パフォーマンスを向上させる事が可能になっています。 SAS 9.4M3から対応されています。この他にも機能拡張されておりますので、詳細はSAS/ACCESSのWebサイトをご覧ください。同様に、分析ソフトとしては、SPSS (IBM)もRedshiftへのプッシュダウンに対応しています。

参考)SAS/ACCESS

(原文):https://aws.amazon.com/jp/about-aws/whats-new/2016/04/amazon-redshift-announces-enhancements-to-data-loading-security-and-sas-integration/

翻訳:下佐粉 昭(@simosako

Amazon RDS MySQLにてMySQL 5.6から5.7へ数クリックでアップグレード出来るようになりました

本日よりAmazon RDS for MySQLデータベースにて、MySQL 5.6から5.7へマネージメントコンソールやAPIを使用して数クリックでアップグレード出来るようになりました。

MySQL 5.7では以下の様な新機能が利用可能になり、MySQL 5.6よりパフォーマンスが向上しています

  • Native support for the JSON data type and built-in JSON functions
  • Optimizer improvements for better EXPLAINing, parsing, and query performance
  • GIS Spatial Extensions
  • Improved parallel replication using logical clock mode
  • Improved InnoDB scalability and temporary table performance
  • Improved tablespace discovery during crash recovery
  • Dynamic buffer pool resizing

MySQL 5.7.11へアップグレードを行う前に、RDS for MySQL upgrade documentationをよくお読みになり、アプリケーションの互換性があるか十分にテストを行って下さい。 Amazon RDSではこれらのプロセスを簡単に行うことが出来ます。まず現在のデータベースインスタンスのスナップショットを取得し、スナップショットより新規インスタンスを作成します。この新しく作成したデータベースインスタンスをMySQL 5.7.11へアップグレードし、アプリケーションのテストを行います。

MySQL 5.7.11でアプリケーションが正常に動作することが確認出来たら、AWSマネージメントコンソールでアップグレードを行うデータベースインスタンスを選択し、ModifyオプションよりMySQL 5.7.11を選択し、ウィザードにしたがってアップグレードを行って下さい。アップグレードは標準で次のメンテナンスウインドウで実行されますが、Apply Immediatelyを選択するとアップグレードを即時実行することも可能です。

どちらの場合でも、アップグレードが完了するまでの数分間データベースインスタンスへ接続出来なくなる点ご注意下さい。

翻訳は星野が担当しました。(原文はこちら)

MariaDB audit plug-inがRDS MySQLとMariaDBでご利用可能になりました

MariaDB audit plug-inがRDS MySQL (5.6.29と5.7.11) とRDS MariaDB 10.0.24 にてご利用頂けるようになりました。MariaDB audit plug-inはアプリケーションの問題を切り分けるためや、コンプライアンスに準拠するためにデータベースのイベントのログを取得することが可能です。プラグインの主な機能は以下の通りです。

  • Enabling and disabling the audit plug-in – オプショングループよりプラグインを有効・無効化出来ます。オプショングループにMARIADB_AUDIT_PLUGINオプションが追加されています。このオプションを設定したオプショングループをRDSインスタンスへ付与することでロギングが有効になります。無効にする場合は、このオプショングループをRDSインスタンスから削除します。
  • SERVER_AUDIT_EVENTS変数 – この変数では取得するイベントの種類を設定可能です。(CONNECTION: ユーザが接続・切断したイベント, QUERY: クエリとその結果, TABLE: クエリによってアクセスされたテーブル)
  • SERVER_AUDIT_EXCL_USERSSERVER_AUDIT_INCL_USERS変数 – この変数で、どのユーザを監査対象にするか・しないかを設定可能です。SERVER_AUDIT_INCL_USERSの設定が優先され、標準では全てのユーザが記録対象となっています。

MariaDB audit plug-in for RDS MySQL, MariaDBはRDSが利用可能なリージョン全てでご利用可能です。

翻訳は星野が担当しました。 (原文はこちら)

Amazon RDS for PostgreSQLで PostgreSQL 9.5(9.5.2)とバージョン9.4.7、9.3.12サポート

本日より、Amazon RDS for PostgreSQLでバージョン9.5のサポートを開始しました。このバージョンではUPSERTやRow Level Security (RLS)、Big Data capabilitiesなど多くの新機能を含んでいます。また、新しいメジャーバージョンに加えて、多くの機能向上やfixを含んだ9.4.7や9.3.12といった新しいマイナーバージョンもサポートしました。。

PostgreSQL 9.5 (マイナーバージョンは9.5.2) は以下の様な新機能を含んでいます:

  • UPSERT: “INSERT, ON CONFLICT UPDATE”を簡単に実行可能です。この機能では行へのINSERTやUPDATEを同時に扱う事が可能で、同時に実行されるデータの衝突を扱うことが可能になり、アプリケーションの開発もシンプルに行えます
  • Row Level Security (RLS): RLSは行や列レベルでデータへのアクセスコントロールを行うことが可能になります。この機能により、セキュアに扱わなければならないデータのコントロールを厳格に行なえます
  • Big Data features: PostgreSQL 9.5はBig Dataシステムと連携出来る多くの新機能を含んでいます。例として、BRIN Indexingは小さいながらも効果的なインデクシングを “naturally ordered”テーブルに行えます。”abbreviated keys”アルゴリズムを用いたfaster sortsはtextやNUMERICフィールドのソートを高速に行います。CUBE, ROLLUP や GROUPING SETSはTableauなどのOLAPツールと連携して複数のレベルのサマリーを用いたレポートを可能にします。IMPORT FOREIGN SCHEMAやJOINプッシュダウンを用いたForeign Data Wrappers (FDWs) は外部データベースとのクエリの連携を簡単・効率的に行うことが出来ます。TABLESAMPLEは高コストのソートを避け、大規模テーブルの統計的サンプルを生成可能です。

PostgreSQL 9.5.2データベースインスタンスは、AWS Management Consoleから数クリックで起動可能です(ドキュメント)。また、既に起動しているPostgreSQL 9.4インスタンスから、バージョン9.5.2へメジャーバージョンアップグレードも可能です。もし、バージョン9.3から9.5へアップグレードを行う場合は、point-and-clickアップグレードを2回行う必要があります。それぞれのアップグレード操作中はデータベースインスタンスに短い時間ですが、接続できなくなります。データベースのアップグレードの詳細はこちらをご覧ください。

PostgreSQL 9.5.2に加えて、PostgreSQL 9.4.7 と 9.3.12のサポートも開始しました。これらのバージョンには、こちらのリストにあるようないくつかの修正や機能向上が含まれています。3つの新バージョンについての詳細は、それぞれのバージョンのリリースノートをご覧ください。

これら3つのバージョンでは、pg_stat_activity内のautovacuumセッションにrds_superuserアクセスを許可することで、autovacuumのステータスを参照することが可能です。PostgreSQL 9.5の新機能のさらに詳細な情報は PostgreSQLの公式サイトで確認頂けます。 Amazon RDS for PostgreSQLをご利用頂くための詳細な情報は、Amazon RDSユーザガイドをご覧ください。

翻訳は星野が担当しました(原文はこちら)

Redshiftアップデート:COPYやUNLOADでIAMロールを指定可能に

Amazon Redshiftにデータを読み込む際(COPY)やエクスポートする際(UNLOAD)、その読み書き先(S3)に対してのアクセスを実現するため、これまではCOPYやUNLOADコマンドの引数にIAMのキー情報(アクセスクリデンシャル)を付与する必要がありました。

これが拡張され、Redshiftクラスターに対してIAMロールを付与して、その付与したロールでCOPY、UNLOADができるようになりました。以下がリリースノートの翻訳です。


1つ、もしくは複数のAWS Identity and Access Management (IAM)ロールをRedshiftクラスターにアサインし、データロードやエクスポート時に使用することが可能になりました。Redshiftクラスターはデータロード時(COPYコマンド)やエクスポート時(UNLOADコマンド)に指定されたIAMロールを使用し、結果としてRedshiftから各種AWSサービス(S3等)への操作時に確実にクリデンシャルを利用することになります。IAMロールを使うことで、SQLにAWSアクセスクリデンシャルを埋め込む必要がなくなり、クラスターのセキュリティを向上し、データのロードやエクスポートをシンプルにします。

Redshiftクラスターは長い時間の(COPYやLOAD)オペレーション時には、定期的にIAMロールを再アシューム(Re-assume)します。つまり、暗号化キーを使ったCOPY、UNLOADする場合においてもコマンドは変更されていません。


 

リリースノート(原文):https://aws.amazon.com/about-aws/whats-new/2016/03/amazon-redshift-now-supports-using-iam-roles-with-copy-and-unload-commands/

翻訳:下佐粉 昭(@simosako

ElastiCache for Redis の更新 – エンジンのアップグレードとスケールアップ

Amazon ElastiCache は、クラウド内のインメモリデータベースのデプロイ、運用、スケールの実行を簡単にするサービスです。ご存知のとおり、ElastiCache では Memcached エンジンと Redis エンジンがサポートされています。

Redis 向けの強化
本日、Redis ベースの ElastiCache クラスターがより詳細に制御できるようになる、ElastiCache の更新をローンチしました。You can now scale up to a larger node type while 保存された情報を ElastiCache に保持したまま (ベストエフォートベース)、より大きなノードタイプにスケールアップできるようになりました。ElastiCache for Redis のエンジンバージョンのアップグレードはこれまでずっと可能でしたが、保存された情報を保ったままでこれを実行できるようになりました。これらの変更は、両方とも、即時適用またはクラスターのメンテナンス期間の適用が実行できます。

ElastiCache for Redis のスケールアップとエンジンアップグレードのために、見えないところでさまざまな戦略が活用されています。スケーリングは Redis レプリケーションをベースにしています。エンジンのアップグレードでは、マルチ AZ がオフになったときにまずフォアグラウンドのスナップショットが使用され (SAVE)、マルチ AZ がオンのときにレプリケーションに続いて DNS スイッチが実行されます。

大きなノードタイプにスケールアップするには、AWS マネジメントコンソールで [Cache Cluster] を選択し、[Modify] をクリックします。新しい [Node Type] を選択し、変更を即時適用するかどうかを決定してから、[Modify] をクリックします。

同様に、新しいバージョンの Redis エンジンにアップグレードするには、新しいバージョンを選択してから [Modify] をクリックします。

この機会に、Redis のバージョン 2.8.24 と互換性のあるエンジンにアップグレードすることをお勧めします。このバージョンには Redis の安定性と堅牢性を高めるための多数の修正と強化が実施されています (その一部は ElastiCache チームによるものであり、詳細については「最新情報」を参照してください)。

これまで同様、同じオペレーションを ElastiCache API によって実行することもできます。 PHP 中での簡単な例を示します (AWS SDK for PHP による)。

PHP
// Scale to larger node size
$res = $client->modifyCacheCluster(['CacheNodeType' => 'cache.r3.4xlarge', 
                                    'ApplyImmediately' => true]);

// Upgrade engine version
$res = $client->modifyCacheCluster(['EngineVersion' => '2.8.24',
                                    'ApplyImmediately' => true]);

// Do both at once
$res = $client->modifyCacheCluster(['CacheNodeType' => 'cache.r3.4xlarge', 
                                    'EngineVersion' => '2.8.24', 
                                    'ApplyImmediately' => true]);

これら 3 つの例すべてで、ApplyImmediately パラメーターは変更がメンテナンス期間ではなく、直ちに適用されることを示しています。

詳細については、Scaling Your Redis Cluster をご覧ください。

サービス開始
この機能は今すぐ利用できます。


Jeff

Amazon RDS for SQL Server – Windows認証のサポート

このブログの常連読者の方は私がAmazon Relational Database Service (RDS)の大ファンであることをご存じだと思います。マネージド型のデータベースサービスとして、リレーショナルデータベースのセットアップ、実行、そしてスケーリングといった日常業務の面倒を見てくれます。

2012年にはじめてSQL Serverのサポートをローンチしました。それからSSLサポートメジャーバージョンアップグレード透過的なデータ暗号化、そしてMulti-AZといった多くの機能を追加してきました。これらの機能はRDS for SQL Serverの適用範囲を広げてより多くのユースケースへの扉を開きました。

多くの組織ではアカウントのクレデンシャルとそれに関連するアクセス権をActive Directoryに保管しています。ディレクトリによりこの情報に対する単一で一貫性のあるソースを提供し集中管理を可能にします。AWS Directory Serviceを使用してAWSクラウド上でMicrosoft Active DirectoryのEnterprise Editionを実行することができますので、次のステップにすすむときです!

Windows認証のサポート
AWS Directory Service for Microsoft Active Directory (Enterprise Edition)に保存されたクレデンシャルを使用してAmazon RDS for SQL Serverに対するアプリケーションの認証ができるようになりました。同じディレクトリにすべてのクレデンシャルを保持することでそれぞれのコピーをさがして更新する必要がなくなるため時間と手間の節約になります。

SQL Serverを実行するデータベースインスタンスを新規に作成するときにこの機能を有効にしてActive Directoryを選択することができます。既存のデータベースに対して有効にすることもできます。こちらが新規にデータベースインスタンスを作成するときにディレクトリを選択するやり方です(新規にディレクトリを作成することもできます):

より詳細は、Using Microsoft SQL Server Windows Authentication with a SQL Server DB Instanceを読んでください。

いますぐ利用可能
この機能はUS East(北バージニア)、US West (オレゴン)、Europe(アイルランド)、Asia Pacific(シドニー)、Asia Pacific(東京)、そしてAsia Pacific(シンガポール)リージョンでいますぐ利用可能ですので今日からつかいはじめることができます。この機能に追加費用はありませんが、AWS Directory Service for Microsoft Active Directoryの通常料金がかかります。

Jeff;(日本語訳はSA渡邉(@gentaw0)が担当しました。原文はAmazon RDS for SQL Server – Support for Windows Authentication

 

 

Redshiftアップデート:COPYやVACUUMの機能向上、クラスターリサイズの速度向上等

Redshiftの新しいバージョン1.0.1040リリースについて、その新機能や修正一覧の説明とメンテナンスの予告が公開されています。

このリリースには以下の新機能が含まれています。

  1. ユーザが定義したしきい値よりも大きい比率でソート済の表は、VACUUMでソートをスキップするように
  2. COPYで条件にそったデータを挿入した場合、ソート済の領域としてマージされるように
  3. 接続ログに、SSLのバージョンとSSLサイファーが記録されるように

1.はVACUUMコマンドの機能改善です。VACUUMは不要領域の削除とソートという2つの機能を持っているのですが、すでに大半の領域がソート済の場合はソート処理自体をスキップすることでVACUUMに掛かる時間を短縮します。

デフォルトではその閾値は95%に設定されていますが、これはユーザが指定することが可能です。VACUUMコマンドが拡張されTO sort_threshold PERCENTという形で指定できます。この数値を100にした場合は(今までと同様)常にソートが実行されるようになりますし、逆に0にするとソートが行われなくなります。この新しいオプションはREINDEXやDELETE ONLY等とも併用可能です。

  • 参考)VACUUMコマンド ※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。

2. ですが、Redshiftの中では表のデータは「ソート済領域」と「非ソート済領域」に分けて管理されています。VACUUMを使ってソートされたデータはソート済領域に保存され、追加データは非ソート領域に保存されます。

今回の機能拡張では、条件を満たした場合にCOPYで追加したデータがソート済領域に追加されるようになります。その条件はマニュアルの以下のページに記載されています。

  • Loading Your Data in Sort Key Order ※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。

 条件は以下の通りで、これらを全て満たしている必要があります。

  • 表がコンパウンドソートキー(Interleaved Sort Keyではなく)を使っていて、かつソートキー列が1つのみ
  • ソートキーの列がNOT NULL
  • 表が100%ソート済か、もしくは空(から)
  • 新しく追加されるソートキー列の値が既存データよりソート順で大きい値を持つ

これは、列に常に大きい値が挿入されるようなケース、つまり時刻がソートキーになっていて、そこに追加で新しいデータを追加し続けるような表構造(時系列でデータを入れ続ける)の場合に役に立ちます。

3.は記述のままですね。STL_ CONNECTION_LOGにsslversionとsslcipherという列が追加されています。もしこのSTL表を定期的に別表やファイルにエクスポートしている場合は、クラスターバージョンが上がった途端に列が増えるのでご注意ください。

この他に、INリスト指定時にスキャン範囲を限定することで速度を向上させる機能や、クラスターリサイズ時の転送スループット向上(リサイズに掛かる時間の短縮)、Window関数利用時にORDER BY句が必須ではなくなるといった機能向上、およびバグの修正が行われています。

この新しいバージョンはこれから約2週間にかけて各リージョンにデプロイされます。適用されるとクラスターのバージョンが1.0.1040になっているはずです。

なお、すでにオレゴンリージョン(US-WEST-2)にはデプロイされていますので、新規にオレゴンでRedshiftクラスターを立ち上げると1.0.1040で起動できます。すぐに新機能を確認したい方はオレゴンで試してみてください。

下佐粉 昭(@simosako

AWS Database Migration Service (DMS)が一般公開に!利用可能リージョンも拡大

WS000009みなさんは、現在リレーショナルデータをオンプレミスのOracle, SQL Server, MySQL, MariaDB, PostgreSQLといったデータベースに保存されていますか?それらのデータをAWSクラウドに実質的なダウンタイム無しで移動させ、スケールアウト可能というメリット、効率化されたオペレーション、複数のデータストレージが用意されている環境に移行する事に興味はありませんか?

もしそうであれば、新しい AWS Database Migration Service (DMS) こそ、みなさんのためのサービスです!去年の秋に開催されたAWS re:Inventで最初の発表がなされ、すでにお客様により1,000を超えるオンプレミスのデータベースがAWSに移行されています。お客様はテラバイト級のデータベースを動かしたままクラウドに移行する事が可能になります。データベースプラットフォームを変えずに移行することも可能ですし、要件により適切な別のデータベースプラットフォームに移行することも可能です。新しいデータベースプラットフォームへの移行を、システム全体のクラウド移行とともに実施する場合は、AWS Schema Conversion Tool がみなさんのスキーマやストアドプロシージャを新しいプラットフォーム用に変換する事をお手伝いします。

AWS Database Migration ServiceはレプリケーションインスタンスをAWS上にセットアップすることで稼動を開始します。このインスタンスはソースデータベースからデータをアンロードし、ターゲットのデータベースにロードします。これは”on-going replicaion”をサポートしており、ダウンタイムを最小にする形でのマイグレーションをサポートします。加えて、DMSは、データ型変換や異機種間データ移動(例:OracleからAurora)といった多くの煩雑な処理を代行してくれます。このサービスはレプリケーションの状況やインスタンスをモニターしており、なにか発生した場合はユーザに通知するとともに、自動的に代替となるインスタンスをプロビジョンします。

DMSは多様なマイグレーションシナリオおよびネットワーク接続のオプションをサポートしています。1つのエンドポイント(※ソースもしくはターゲットのデータベースサーバ)はAWS上にある必要がありますが、他はオンプレミスでも、EC2上のデータベースでもRDSでもかまいません。ソースとターゲットは両方が同じVirtual Private Cloud (VPC)上にあっても良いですし、別々のVPC上でもかまいません(AWS上で稼動するデータベースを別のVPC上に移すようなケース)。オンプレミスのデータベースに対してもパブリックインターネット経由で接続するか(インターネットVPNを使うことも可能です)、AWS Direct Connectで接続することが可能です。

データベースをマイグレーションする

数クリックでマイグレーションをセットアップすることが可能です!ターゲットデータベースを作成して、データベーススキーマを移行し、データレプリケーションプロセスをセットアップし、最後にマイグレーションを実行するだけです。ターゲットデータベースがソースの内容に完全にキャッチアップできたら、あとは本番環境から利用するデータベースを切り替えるだけです。

AWS Database Migration Service コンソールを選択して、”Create Migration“をクリックします。(AWS Migration Serviceコンソールは、AWSマネジメントコンソールのデータベースのセクションに「DMS」と書かれたアイコンで表示されています)

 

コンソールにはマイグレーションプロセスのオーバービューが表示されています:

Nextをクリックして、レプリケーションインスタンス作成に必要なパラメータを入力します:

このブログポストでは、既存のVPCを選択し、”Publicly accessible”のチェックを外しています。同僚の社員が、私のためにEC2上に”オンプレミスDB”役のデータベースをセットアップしてくれているからです(訳注:オンプレミスのサーバと、VPNやDirect Connectを使わずにグローバルIP経由で接続するような場合は、ここでPublic accessibleをオンにする必要があります):

レプリケーションインスタンスが作成されると、ソース、ターゲットの両データベースのエンドポイントを指定し、”Run test“をクリックしてエンドポイントに問題なくアクセスできるかを確認します。(正直に告白すると、テストをパスするために自分のセキュリティグループ設定を何度か修正するることで時間を費やしました)

そしてマイグレーションタスクを作成します。Migration typeのところで、”migrate existing data(既存データの一括ロード)”,”migrate and then replicate(一括コピーをした後に、継続的に差分レプリケーション)”,”replicate going forward(差分レプリケーションのみ実行)”の3種類から選択が可能です。

Task Settingsをクリックすることで、追加のオプションを選択可能です(LOBというのはラージオブジェクトのことです):

マイグレーションタスクが準備完了になりました。タスクを選択してStart/Resumeボタンを押すことですぐに実行することが可能です:

実行中の状況を確認することが可能です。また表へのアクセスの統計情報(Table statistics)によって、何が起こっているのかを把握することが可能です(この図はテスト用の表を使った結果なので、あまりエキサイティングな図ではないですが):

 ここまで来たら、あとはデータの正当性をチェックし、アプリケーションを新しいエンドポイントに向けるだけです。上記は一括ロードの例ですが、継続的なレプリケーション(ongoing replication)を選択することも可能です。

AWS Database Migration Serviceは多様なオプションを提供しており、上記はあくまで少し機能を紹介したに過ぎません。例えば、特定の表だけをマイグレーションしたり、複数の異なるレプリケーションタスクを作成し、それぞれ個別に実行することも可能です。DMSのドキュメントを読まれることを強く推奨します。マイグレーションを始めて行う人向けの良いガイドになっています。

多くのデータベースを移行する必要があり、作業を自動化したい場合は、AWS Command Line Interface (CLI) もしくはDatabase Migration Service APIを利用することができます。

費用と稼動リージョン

AWS Database Migration Serviceは US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney) の各リージョンに存在します。そして本日より利用可能です!(私達は他のリージョンへの拡張を今後数ヶ月で検討しています)

Jeff;

原文:https://aws.amazon.com/jp/blogs/aws/aws-database-migration-service/

翻訳:下佐粉 昭(@simosako

 

Amazon Auroraのリードレプリカで、フェイルオーバーの順番を指定可能になりました

本日、Amazon Auroraクラスタ中のレプリカノードを昇格させる順番をご指定頂けるようになりました。この機能により、フェイルオーバ発生時のレプリカノードの昇格を扱いやすくなりました。マスターインスタンスに障害などが発生した場合、Amazon RDSは優先順位が高いレプリカノードを昇格させます。低い優先順位を指定することで昇格させたくないレプリカインスタンスをご指定頂けます。例えば、バッチや集計用途などでご利用頂いているレプリカノードに対して低い優先順位を指定することで、昇格を防ぎバッチや集計作業の影響をアプリケーションに与えることを防ぐことも可能です。

フェイルオーバの優先順位は

指定した優先度
優先度が同じレプリカが複数ある場合は、フェイルオーバ発生時のマスターインスタンスよりインスタンスサイズの大きいインスタンス
優先順位もインスタンスサイズも同じ場合は、同じ優先順位のレプリカノードから任意のレプリカノードが選択されます

さらに詳細なフェイルオーバのロジックや優先順位についてはAmazon Auroraユーザガイドをご覧ください。Amazon Auroraについてはプロダクト紹介ページをご覧ください。

— 星野 (原文はこちら)