デフォルトのRDSキーで暗号化されたスナップショットの共有 - Qiita
概要 RDSのスナップショットを共有する際、デフォルト以外のAWS KMSを利用した暗号化であれば、問題なく行える。 AWS 公式 - 暗号化された Amazon RDS DB スナップショットを別のアカウントと共有する方法 ただ、デフォルトの暗号化キーで暗号化されたスナップショットを共有(上図のShare)できない。 予想ですが、デフォルトの暗号キーを別アカウントに共有できないためだと思われる。 デフォルトの AWS KMS 暗号化キーを使用して、暗号化されたスナップショットを共有することはできません。 とAWS公式も無理だと言っていますが、以下の手順で共有が可能でした。 スナップショットを取得する。 KMSにてカスタマー管理型のキー(CMS)を作成する。 CMSを共有する。 スナップショットをCMSで暗号化してコピーする。 スナップショットのコピーを共有する。 共有したスナップショット
RDSでDBをスナップショットから復元する - Qiita
こんにちはみなさん サービスを更新するとき、ときには現時点でのデータベースのデータ構造に手を入れる必要が出てくるかもしれませんが、そんなときは必ずバックアップをとっておくものです。 随分前であれば、mysqldumpとかを使って生のダンプファイルを取っておいて、復旧時はそのダンプファイルを入れ直すというふうにやっていたと思うのですが、AWSのRDSではスナップショットを定期的に、もしくは能動的に取得することができ、このスナップショットからDBを復元するという手段があるので、それを頼りにする場合があるでしょう。 私の場合は、コンテナ運用時にはそもそもRDSへ直接アクセスする手段を封じていますので、スナップショットによる復元以外には (セキュリティグループの設定を変えたりしない限り) 方法がありません。 そんなわけで、RDSでスナップショットからDBを復元するときに、引っかかりそうになった部分
CloudFormationでRDSを更新する時の注意 - Qiita
背景 CloudFormationで管理しているMariaDBインスタンスのパブリックアクセスを変更したかったのですが スタックファイル(json)から更新すると以下のエラーでハマりました。 CloudFormation cannot update a stack when a custom-named resource requires replacing. Rename (DBインスタンス名) and update the stack again. 公式ドキュメントを読んで見ると InstanceIdentifier 重要 名前を指定すると、このリソースの置換が必要な更新はできません。中断が不要であるか、一定の中断が必要な更新であれば、行うことができます。リソースを置き換える必要がある場合は、新しい名前を指定します。 CloudFormationで、DBInstanceのInstanc
スナップショットからRDSインスタンスを作成する方法 - Qiita
はじめに "出来合いのDB"のスナップショットからクローンとなるRDSインスタンスを作る機会があったので、その手順をまとめてみました。 スナップショットの選択 AWSマネジメントコンソールのトップ画面から、［サービス］>［RDS］と進みます。 RDSの画面の左側のパネルで、［スナップショット］を選択します。 スナップショット画面が開いたら、所望のスナップショットにチェックを入れます。 その後、スナップショット画面上部の［スナップショットのアクション］のリストをクリックして、［スナップショットの復元］を選択します。 スナップショットの復元 DBインスタンスの復元画面で、以下の事項を設定します。 設定が完了したら、画面最下部の［DBインスタンスの作成］ボタンをクリックして、スナップショットからRDSインスタンスを作成します。 インスタンスの仕様 DBエンジン ライセンスモデル ライセンス込み（
AWS Backupを使い始める前に覚えておきたいこと - Qiita
AWS Backup is 何 AWS上のバックアップを一元的に管理できるAWS Backupが利用可能になりました。 AWS Backup – Automate and Centrally Manage Your Backups https://aws.amazon.com/jp/blogs/aws/aws-backup-automate-and-centrally-manage-your-backups/ ※以降は2019/1/17 時点の情報です。 2019/6/27 に東京リージョンで利用可能になったため情報を更新しました 2020/1/14 時点の情報に更新しました 2020/6/11 Aurora に対応したため追記しました バックアップ取得可能なリソース 2020/11/11時点 EFSファイルシステム DynamoDBテーブル EC2インスタンス(EBS-backedのみ)
LambdaとRDSで爆死してみる - Qiita
2019/12/05 Update こちらにRDS Proxyが発表されましたので、この投稿の内容はアンチパターンではなくなる可能性があります。 内容 LambdaとRDSは相性が悪い(というより、一緒に使うべきではない)というのはよく聞く話です。百聞は一見にしかずということで、爆死してみました 2019/07/19 Update こちらに続編を書きました 事前情報 なぜ相性が悪いかはこちらを。 http://keisuke69.hatenablog.jp/entry/2017/06/21/121501 https://qiita.com/teradonburi/items/86400ea82a65699672ad やってみる(概要) s3へのファイルPUTをトリガーにLambdaを起動させ。RDSのテーブルに「バケット名」と「ファイル名(key)」をInsertします この検証では、10
Lambda+RDSはアンチパターン - Qiita
何が起きたのか 作成していたアプリではサーバレス構成にてLambdaからRDS(MySQL)を呼び出していました。 リクエストが増えるとRDSのコネクション数が増加して すぐにDBコネクションエラーになってしまいました。 最大コネクションの上限値 結論から言うとLambdaとRDS(MySQL)は相性が良くないです。 理由はLambdaからRDSのDBコネクションを貼ると リクエスト単位でコネクションを張ってしまうため 仕組み上、同時接続に耐えられません （RDSのコネクション上限数が少ない） さらにVPC設定すると・・・ セキュリティのため、RDSをLambdaからのみアクセスさせるためには LambdaとRDSを両方とも VPC領域に置く必要があるのですが、Lambdaの起動が遅くなる場合があります。 これは、一定時間Lambdaがコールしない場合にスリープ状態になり、 起動する際にE
AWS Lambda(Node.js)からAmazon RDSへIAM認証で接続する - Qiita
概要 現在開発しているburariというおでかけアプリでは、APIGatewayからLambdaを実行し、RDSのデータを取得している。 以前まで、LambdaからRDSへの安全な接続にはVPCが必須となっており、AWS Lambdaの定期実行をSAMを使って実装するにも書いたとおり、コールドスタート問題が懸念になっていたが、IAM認証でLambdaからRDSに接続できるようになったため、ついにVPCから解放される日がきた。VPCから解放されることにより、LambdaからSNSやKMSへの接続にNATが不要になるため、お財布にも優しいサービス運営が待ち受けている。 今回は接続まわりを実装してみる 💪💪 環境 Amazon RDS (MySQL v5.7.17, t2.micro) AWS Lambda (Node.js v8.10) Sequelize (ORM for Node.js
Lambda + RDS benchmark - Qiita
はじめに LambdaからRDSに接続する時に、Lambdaでは全てのプロセスが独立してしまうので、connectionも使いまわすことが出来ません。 このため、Lambdaに対する同時接続数を増やしていくと、RDS側でconnection数が上限を超えた時にエラーになります。 ※ただ、これはLambdaに限らず、Connection Poolingが出来ないシステムでは同じです。 このことにより、Lambda+RDSはアンチパターンであるという見方をすることがあるようです。 結論 Lambdaを利用してもRDSのmax connection設定"だけ"が原因でスループットが実用に耐えなくなるということはなさそう。(即アンチパターンというわけではさそう) [追記]RDSがSingleAZの場合、(試験した範囲では)インスタンスタイプを変えることでスループットをスケールすることができる。 [
AWS LambdaでAmazon RDS for MySQLへ接続する(Node.js 4.3 + KMSで暗号化したMySQL接続パスワードをkms.decryptで復号化してMySQLヘ接続 + バッチ実行をSNS通知する) - Qiita
AWS LambdaでAmazon RDS for MySQLへ接続する(Node.js 4.3 + KMSで暗号化したMySQL接続パスワードをkms.decryptで復号化してMySQLヘ接続 + バッチ実行をSNS通知する)Node.jsMySQLAWSlambdakms はじめに Node.js 4.3でAWS Lambdaファンクションを作成し、MySQL(Amazon RDS for MySQL)へ接続するサンプルです。 Lambdaファンクション内のMySQL接続パスワードは平文ではなく、AWS Key Management Service(KMS)により暗号化したMysQL接続パスワード文字列を記載し、Lambdaファンクション実行時にkms.decryptでパスワードを復号化してMySQLデータベースへ接続します。 また、Lambdaファンクションの実行をAWS SNSで
Amazon RDS で max_connections が変わらなかった - Qiita
今北産業 max_connections がおかしい時は、 一旦適当な数字に変えてから 戻してみよう kwsk m1.medium の RDS インスタンスを動かしてるのに、なぜか が 151 という結果を返してきた。RDS での max_connections は、デフォルトでは {DBInstanceClassMemory/12582880} になるはずなんだけど、151 という数字は少なすぎる。 m1.medium のメモリは 3.75 GB だから、値としては 3.75 * 1024 * 1024 * 1024 / 12582880 = 320 になるはず。 とりあえず値を直接 320 と指定してみたところ、先ほどの select 文は 320 を返すようになった。なんだ変わるじゃん。ってことで、再度 {DBInstanceClassMemory/12582880} に戻したら、今
AuroraとRDS MySQL 5.7のsysbench - Qiita
この記事を見て、結果に疑問を持ったので、AuroraとRDS MySQL 5.7のベンチマークを取ってみました。 動作環境 サーバ Aurora 5.6.10a / db.r3.large / SingleAZ MySQL 5.7.10 / db.r3.large / SingleAZ io1 / 100GB / 1000iops 設定はそれぞれ以下を変更 sync_binlog = 0 innodb_flush_log_at_trx_commit = 2 クライアント 4.1.17-22.30.amzn1.x86_64 / c4.2xlarge sysbench 0.4.12 サーバとクライアントはすべて同じAZ 並列数を高くできるように以下の値を増やした max_connections max_prepared_stmt_count nofile テストスクリプト --oltp-tab
Serverless 使って Lambda から RDS を使用する - Qiita
先日 Lambda の VPC サポート実装がアナウンスされてたので試してみました。 VPC サポートの実装により、Lambda と RDS, ElasticCache などを連携させられるようになりました。 使ってみた所感としては、今まで用途が限定されていた気がする Lambda の使いどころがかなり広がったんじゃないかと思います。 小規模な案件なら本当にサーバいらなくなるんじゃないでしょうか。 諸々インストール フレームワークは jaws の後継 serverless を使います。 動作には node V4 が必要です。 作業は適当に立ち上げた EC2 インスタンス上で行いました。 $ git clone git://github.com/creationix/nvm.git ~/.nvm $ source ~/.nvm/nvm.sh $ nvm ls-remote # 最新のバージョ
【AWS】CloudWatchでの監視項目まとめ - Qiita
どうも、iron千葉(((( ;°Д°))))です。 AWSでは、手っ取り早く監視ができるCloudWatchというマネージドサービスがあります。 オンプレの場合、可用性・ディスク容量等を考慮して監視サーバを導入する必要がります。 これに比べ、AWSで監視を行う場合、例えばEC2を作ったらメトリックス（CPU使用率など）が自動で取得されます。 AWSで監視を行うには、 SNSのトピックを作る CloudWatchより、メトリックスを選択し閾値を設定する のみで、とてもスマートに監視を開始できます。そして、閾値を超えた場合メールが飛んできます オンプレでの苦労はなんだったのか！ ただし、制限事項もあります。 CloudWatchのデータは２週間保存。それ以前のデータは破棄されるのでご注意ください。それ以前のデータが欲しい場合は、こちらを参照して取得する必要があります。 また、デフォルトで取得
Fluentdを使ってRDSのSlowLogをSlackに通知する - Qiita
これはなにか RDSのSlowLogをSlackに通知したかった。 AWSのAPIで download-db-log-file-portion があったが通知するには使い勝手が悪かったので MySQLのテーブルにSlowLogを保存して、それをFluentdからSELECT & Clear をすることにした。 この記事はMysqlの設定なので、他のDBの場合はよしなに変更してください。 使ったもの fluent-plugin-slack : https://github.com/sowawa/fluent-plugin-slack fluent-plugin-rds-slowlog : https://github.com/kenjiskywalker/fluent-plugin-rds-slowlog RDSの設定 Parameter Group slow_query_log : 1 l
Datadog で RDS Postgresql をモニタリングする - Qiita
はじめに Datadog で RDS をモニタリングしようと思った場合は、 CloudWatch (AWS) 連携 Postgresql 連携 が利用できる。 また、Sensu で監視したメトリクスを Datadog に送ることも可能。 sensu と datadog を連携してちょっとリッチなメトリクスの可視化 - inokappa に丁寧に書かれてる。 CloudWatch 連携 Datadog 用 IAM ユーザを用意する AWS 連携を有効にするには予め read-only の datadog 用 IAM ユーザを作成しておく。 必要な権限 連携を ON にする Integration タブから "Available" 一覧から "Amazon Web Services" を選択し、"Install Integration" その際に、 datadog 用の Access Key
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDS(Mysql)のMaxConnection数 - Qiita
【AWS】それぞれのDBの特徴を簡単にまとめました(備忘録) - Qiita
RDSでtrx_mysql_thread_idが0のトランザクションが残ってしまったときの対応方法 - Qiita