Amazon RDS リソースの暗号化オプションを有効化すると、AES-256 暗号化アルゴリズムにより以下のデータを暗号化することができます。 ※対応しているインスタンスクラスや制限事項についてはAmazon RDS リソースの暗号化をご確認ください。 DB インスタンス 自動バックアップ リードレプリカ スナップショット ログ 暗号化オプションはDB インスタンスの作成時にのみ有効にすることができ、作成後のインスタンスでは有効にすることができません。ただし暗号化されていないスナップショットのコピーは暗号化することが可能です。 そのため暗号化してコピーしたスナップショットから暗号化されたインスタンスを復元することができます。 今回は、暗号化していない既存インスタンスを暗号化オプションを有効化にしたインスタンスにする方法をご紹介します。 要件 MySQLエンジンの暗号化オプションを有効にし
「このRDS、暗号化できたらいいのにな」ってこと、ありませんか？ ネットセキュリティ対策が求められる昨今、稼働中のRDSが「暗号化」されていないものも多少なり存在していると思います。 コンプライアンス要件の達成も含め、掲題のようにお考えの方もいいらっしゃるのではないでしょうか？ そこで今回は、稼働中のRDS暗号化の方法・手順をご紹介します。 RDSを暗号化するメリット 文字通り、RDSのデータ保護が最大のメリットになります。 万一、AWSデータセンタへ不正アクセスや侵入被害にあった場合に効力を発揮しますので、リスクヘッジとしては大きな役割を担います。 ※XSSなどによるアプリケーションの脆弱を突かれた場合、RDS暗号化では侵入・漏えいは防げません。 一方で暗号化によるRDSパフォーマンス低下が気になるところですが、大幅なパフォーマンス低下はなさそうです。それでも不安という方は、負荷テストを
こんにちわ！OCEAN'Sの大庭です。 今回は、本番環境でRDSのスケールアップを行いましたのでその手順とログを紹介していきます 概要 まず、RDSがSingle-AZ構成のままスケールアップを行うと、 インスタンス停止 インスタンスタイプの変更（スケールアップ） インスタンス起動 となってしまい、DBサイズにもよるがサービスダウンタイムが10分弱はかかってしまいます。 そのため、今回は以下の方法でスケールアップを行います RDSをMulti-AZ構成に変更 RDSのスケールアップ プライマリにフェイルバック RDSをMulti−AZに変更 まず、RDSをMulti−AZ構成に変更する。 Multi-AZ構成への変更はダウンタイムが発生しませんが、 シングル AZ からマルチ AZ への変換時のダウンタイムを回避できますが、マルチ AZ への最初の変換時にパフォーマンスに大きな影響が出るこ
RDSフェイルオーバーによるダウンタイムの実測（PostgreSQL編） オンプレミスなシステムをAWSに移行する際など、DBサーバにはRDSを使うかという点がよく議論になります。RDSは非常に便利ですが、導入の検討段階で「定期メンテナンスやフェイルオーバーでダウンタイムが発生するからNGになった」という話をよく聞きます。 ダウンタイムはどの程度か、という話はAWSの公式サイトにも記述があり、「通常」60～120秒とされています。可用性担保を使命とするエンジニアとしては、この「通常」という言葉がとても気になりますよね。 ということで、今回はRDSのフェイルオーバーによるダウンタイムを実測してみました。
はじめに AWSチームのすずきです。 マルチAZ構成で作成されたRDS(MySQL)は、メンテナンスウィンドウによるインスタンスタイプやストレージ容量の変更後、 マスタDBの稼働するアベイラビリティーゾーン(AZ)がフェイルオーバーにより変化する事があります。 【AWS】RDSのインスタンスタイプ変更にかかる時間を調べてみた EC2とRDS間の通信がクロスAZとなる事で、レイテンシの増加やAZ間のネットワーク転送費(0.01$/GB)が問題となる環境で、 手動フェイルオーバーを実施する機会がありましたので紹介させて頂きます。 構成図 EC2、RDS間の通信がクロスAZとなった環境(右)、フェイルバックにより復旧させました。 操作 再起動 手動(強制)フェイルオーバは、RDSの再起動で実施します。 「フェイルオーバし再起動」をチェックし、再起動を行います。 通常、数分でフェイルオーバが完了、
拡張モニタリングを使用した OS メトリクスのモニタリング - Amazon Relational Database Service
Enhanced Monitoring を使用すると、DB インスタンスのオペレーティングシステムをリアルタイムでモニタリングできます。さまざまなプロセスまたはスレッドが CPU をどのように使用しているかを確認するには、Enhanced Monitoring メトリクスが役立ちます。 Enhanced Monitoring の概要 Amazon RDS には、DB インスタンスが実行されているオペレーティングシステム (OS) のリアルタイムのメトリクスが用意されています。RDS DB インスタンスのすべてのシステムメトリクスとプロセス情報をコンソールに表示できます。各インスタンスでモニタリングするメトリクスを管理し、要件に応じてダッシュボードをカスタマイズできます。拡張モニタリングメトリクスの説明については、「拡張モニタリングの OS メトリクス」を参照してください。 RDS は、拡張
突然ですが皆さん、RDS、使ってますか？ こんにちは、クラウドエンジニアの大田です。 先月8月23日に起こった東京リージョンでの大規模障害が起きて久しいですね。 当初単一AZでの影響のみと考えられていた障害でしたが、 RDSやALBでのInternal Server Errorを吐いていたことが分かり、 障害の影響はマルチAZ配置のシステムにも波及していました。 「ウチはマルチAZでフェイルオーバーするから安心！」と思っていたらRDSが停止または自動再起動していた…という方もいらっしゃったのではないでしょうか。 さて、今回のテーマは「RDSのフェイルオーバー時の挙動を理解してみる」です。 主なゴールは、RDSのフェイルオーバー時の挙動を学び、安定稼働のためのヒントを得ていただくことです。 思考停止でとりあえずRDS使っとけ！的な風潮はありますが、やはり内部の動きを正確に理解しておかないと、
MySQL 8.0でLOAD DATA LOCAL INFILEが "ERROR 1148 (42000): The used command is not allowed with this MySQL version" または "Error: 3948. Loading local data is disabled; this must be enabled on both the client and server sides" で失敗する時
MySQL 8.0でLOAD DATA LOCAL INFILEが "ERROR 1148 (42000): The used command is not allowed with this MySQL version" または "Error: 3948. Loading local data is disabled; this must be enabled on both the client and server sides" で失敗する時 MySQL 8.0.19とそれ以降ではエラーメッセージが "Error Code: 3948. Loading local data is disabled; this must be enabled on both the client and server sides" に変わりました（それ以前は "ERROR 1148 (42000):
しばらく時間が空くと忘れてしまうので備忘録。 dockerでmysqlサーバーを立てた時にありがちなパターンをまとめた。 今回はmysqlの公式イメージを使う前提。 起動時に初期データとユーザー追加起動時にテーブルを作成したり、データを追加したい時、ユーザーを追加しておきたい時。 例えば、以下のようなユーザー追加と初期データ追加用のsqlファイルを任意のディレクトリ(今回はinit.dにしておく)に置いておき、 #! /bin/bash CREATE_USER='mysql' CREATE_PASSWORD='secret' GRANT="GRANT ALL ON ${MYSQL_DATABASE}.* TO ${CREATE_USER}@'%' IDENTIFIED BY ${CREATE_PASSWORD}; FLUSH PRIVILEGES" echo $GRANT | mysql
As Rene wrote on the ProxySQL blog yesterday: Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck. This is indeed something we have observed in the MySQL team for a while. Before we get to the subject of today’s post, let me start with an introduction. Introduction to Query Cache The MySQL query cache is a quer
データベースについてのそもそも論
先月のはじめのほうで、「リレーショナルデータベースとの上手な付き合い方」というタイトルで、2回発表をした。ひとつは「まべ☆てっく Vol.1」であり、もうひとつは「Hacker Tackle（ハカタクル？）」である。 「リレーショナルデータベースの開発・運用に纏わるもろもろの話をして欲しい」というような内容の話をしてくれないかという同じような依頼を、ちょうど2日違いのイベントで頂いた。9/8のまべ☆てっくと、9/10のHacker Tackleである。そうなると必然的に話す内容も、同じようなものになってくる。同じ人物（＝私）が話すのだから、テーマも同じで時期も同じであれば、内容が同じようなものになるのが自然である。もし違うものになってしまっているのであれば、片方はウソをついているということになるはずだ。今日は発表に使用したスライドを紹介しつつ、なぜデータベースを使うべきなのか（あるいは使う
We’ve represented the old version in red and the new row version in green. Under the hood, Postgres uses another field holding the row version to determine which tuple is most recent. This added field lets the database determine which row tuple to serve to a transaction that may not be allowed to see the latest row version. With Postgres, the primary index and secondary indexes all point directly
CentOS 6.4にMySQLをrpmで入れることにする。MySQLは、5.6系はまだ初物すぎるので5.5系を入れようか。 ダウンロード まずはOSデフォルトのyumリポジトリから入れようかと、バージョンを確認。 [ozuma@paracent ~]$ yum info mysql.x86_64 Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: ftp.iij.ad.jp * extras: ftp.iij.ad.jp * updates: ftp.iij.ad.jp Available Packages Name : mysql Arch : x86_64 Version : 5.1.67 Release : 1.el6_3 Size : 886 k Repo : updat
MySQL User Conference Tokyo 2015で発表しました：MySQL 5.7におけるオプティマイザの改良点
昨日、告知させていただいたMySQL User Conference Tokyo 2015で登壇したので、その時の資料を公開した。MySQL 5.7の機能は全部ひとつのスライドで紹介しようとすると、多すぎて私にはコンパクトにまとめるだけの技量は無いため、今回はオプティマイザだけの紹介にした。興味のある方はご覧頂きたい。 そういえばすっかり忘れてしまっていたのだが、MySQL 5.7が登場した！！というブログエントリを書くのを忘れていた。もしかすると読者の皆さんの中には、MySQL 5.7が正式リリースされたことをご存じない方もいらっしゃるかも知れない。遅くなって申し訳ないが、MySQL 5.7は、バージョン5.7.9をもって正式版となっている。5.7.9は約2ヶ月前にリリースされた。ついでに言うと、バグ修正を含んだ5.7.10が既に出ている。 MySQL 5.7はまさにモンスターだ！！！と
1 MySQL 5.6における大量データロード時の考慮点 第18回 AWS User Group - Japan 東京勉強会 2013/10/04 平塚 貞夫 2013/10/07 Revision 2 2 自己紹介 • DBエンジニアやってます。専門はOracleとMySQL。 – システムインテグレータで主にRDBMSのトラブル対応をしています。 – 仕事の割合はOracle：MySQL：PostgreSQL＝5：4：1ぐらいです。 • Twitter：@sh2nd • はてな：id:sh2 • • 写真は実家で飼っているミニチュアダックスのオス、アトムです。 3 本日のお題 4 InnoDBデータベース 大量データ投入 • 日本HPさんが以下の検証結果を公開されています。すばらしい資料です。 http://h50146.www5.hp.com/products/software/oe
#yapcasia でMySQL 5.7の罠についてLTしてきました
ネタ的には 発掘するたび書き溜めてきたブログ記事 から 笑いが取れそうなものを 大事そうなもののみをピックアップして紹介した感じです。 知らないと致命傷、でも知ってれば予防できる（はず） MySQL 5.7で不幸になる人が1人でも少なくなってくれることを願っています。 さて、今年のYAPC::Asiaはメイントラックもトークを応募していたのですが見事に落選したので、1日目は完全にリラックスして過ごしました。LTの採否、当日になるまでわかんないのか大変だなーとか、他人事だったんですが、 1日目のLT見るじゃないですか。 面白いじゃないですか。 俺もしゃべりたくなるじゃないですか。 なったんですよ！！１ が、翌朝になってLTの応募ページをたどってみると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
