RDS †
ログの分析 †
スナップショットをS3へエクスポート †
RDS proxy: コネクションプールを提供 †
アプリケーションとRDSデータベースの間の仲介役。
Lambda等のアプリ側で、コネクションプールや自動フェイルオーバー機能を持ってない場合等。
SSL/TLS接続 †
- 注意点
- SSL/TLS接続は使っていないつもりでも、内部的にチェックをしていて問題がでるケースがある。->更新しよう
- 放置しても rds-ca-2019 へは自動更新されなかった
- mysqlコマンドがエラーになる場合、「-ssl-mode DISABLED」を付ける。デフォルトが「PREFERRED (証明書が使えるなら有効)」
トラブルシューティング †
Storage Auto Scaling: ストレージの自動拡張 †
- Storage Auto Scalingの条件
- DBInstanceClass: db.m4, db.t2以上。db.m3等の古いインスタンスタイプはサポートされない。
- StorageType: gp2, io. standardはサポートされない。
aws rds describe-orderable-db-instance-options \
--engine mysql \
--engine-version 5.6.44 \
--vpc \
--profile example \
--region ap-northeast-1 > rds.mysql.5.6.44.json
cat rds.mysql.5.6.44.json | jq -r '.OrderableDBInstanceOptions[] | [.DBInstanceClass, .StorageType, .SupportsStorageAutoscaling] | @tsv' | sort
PostgreSQL †
セキュリティ †
パフォーマンスチューニング †
監査ログ †
ストレージタイプの変更 †
ClassicからVPCへ移行 †
VPC上のRDSにElasticIPを付与 †
VPC上のRDSは名前解決すると、プライベートIPになるため、VPC以外からアクセスできない。
ElasticIPをVPC上に取得し、それをRDSに付与する事で外部からでもアクセスできる。
DBエンジンのアップグレード †
- MySQL 5.5から5.6へのアップグレード
- ダウンタイムはMultiAZ:falseで約6時間。trueで約35分。read replicaを使えばよりダウンタイムを短く出来る
- Instance type: m3.medium / DB size: 50GB
- mysql5.5のread replicaの作成：約10分
- storage typeをstandardからgp2へ変更：約2時間
- mysql5.6から5.6へのアップグレード：約3時間 (m3.largeだと約35分)
- read replicaをmasterへ昇格：1分
- 古いRDS IDを適当に変更。新しいRDS IDを古いRDSと同じにする
タイムゾーンの変更 †
- パラメータグループの「time_zone」に「Asia/Tokyo」を入れる事ができるようになっている。2016-01-26現在
- init_connectを変更していた場合、空にはできないのでダミーの値をいれる
レストア †
オンプレミスのMySQLからRDSへの移行 †
サービス停止する変更 †
- MultiAZが前提だが、サービス停止する場合としない場合がある
- サービス停止する
- インスタンスタイプの変更。5分程度のサービス断が起こる
- ストレージタイプの変更(standard => gp2等)。2分程度のサービス断が起こる
Automated Snapshotが出来ない †
- AWS supportの回答では、「日時バックアップ(Backup Window)の開始前の直近にバックアップが行われた場合、通常行われる日時バックアップがスキップされることがある」
- 緊急のminor version upgradeされたときに、Automated Snapshotがスキップされた。
デフォルトのmax_connectionsはメモリサイズによって変わる †
Management Consoleで任意の値に変更可能
mysqldump --all-databasesでAccess Deniedになる場合 †
RDS起動直後は status=available になっても接続できない場合がある †
- スクリプト等で status=available に変わるのをチェックして、接続しに行くもエラーになる事がある。AWSプレミアムサポートの回答は"仕様"との事。3分以上かかるのは希だと。mysqlコマンドで接続チェックしたほうが良さそうだ
ARN †
テーブル圧縮 †
Zabbixで監視 †
RDS slow log/クエリログの有効化 †
- RDSはsshで接続できないのでログを直接みる事が
できない。~AWS Management ConsoleおよびAmazon RDS APIを使うとできるようになった。
- パラメータグループで「log_output = TABLE」を有効にするとTABLEに出力される
- mysql.general_log : 全てのクエリを記録
- test_param_group に対して、「general_log:ON」
rds-modify-db-parameter-group test_param_group -p "name=general_log, value=1, method=immediate"
- 直近10件の取り出し
echo "select * from mysql.general_log order by event_time desc limit 10;" \
| mysql --default-character-set=utf8 -u root -p -h mydb.xxxxx.ap-northeast-1.rds.amazonaws.com mysql
- mysql.slow_log : スロークエリのみ記録
- ManegementConsoleからはslow_query_logは数分後に変更されたが、long_query_timeはすぐには変更されなかった。
- test_param_group に対して、「スローログの記録:ON」、「3秒以上かかるクエリの記録」、「10000行以上を対象にするクエリを記録」。数分で適用
rds-modify-db-parameter-group test_param_group -p "name=slow_query_log, value=1, method=immediate"
rds-modify-db-parameter-group test_param_group -p "name=long_query_time, value=3, method=immediate"
rds-modify-db-parameter-group test_param_group -p "name=min_examined_row_limit, value=10000, method=immediate"
- 確認
mysql -uroot -p -h mydb.xxxxx.ap-northeast-1.rds.amazonaws.com mysql
SHOW global VARIABLES LIKE 'slow_query_log';
SHOW global VARIABLES LIKE 'long_query_time';
SHOW global VARIABLES LIKE 'min_examined_row_limit';
- 直近10件のslow logの取り出し
echo "select * from mysql.slow_log order by start_time desc limit 10;" \
| mysql --default-character-set=utf8 -u root -p -h mydb.xxxxx.ap-northeast-1.rds.amazonaws.com mysql
タグの取得 †
![[PukiWiki]](image/owl.png "[PukiWiki]")
