Category: AWS RDS

– general_log: all queries log
– slow_query_log: slow query, long-running queries logs
– long_query_time: slow query time, second

うーん、全部見れれば盤石のような気もするが、ケースバイケースのようにも見えますね。。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html

MySQL エラーログ、スロークエリログ、一般ログをモニタリングできます。MySQL エラーログはデフォルトで生成されます。DB パラメータグループのパラメーターを設定することで、スロークエリと一般ログを生成できます。Amazon RDS では、すべての MySQL ログファイルはローテーションされます。次に、ログファイルのタイプごとのローテーション間隔を示します。

うむ、わかった。

MySQL バイナリログ形式を設定するには
https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。
ナビゲーションペインで、[パラメータグループ] を選択します。
変更する DB インスタンスで使用するパラメータグループを選択します。
デフォルトのパラメータグループを変更することはできません。DB インスタンスがデフォルトのパラメータグループを使用している場合、新しいパラメータグループを作成し DB インスタンスと関連付けます。
DB パラメーターグループの詳細については、「DB パラメータグループを使用する」を参照してください。
[Parameter group actions (パラメータグループのアクション)] で、[Edit (編集)] を選択します。
binlog_format パラメータを、選択したバイナリログ記録形式 (ROW、STATEMENT、または MIXED) に設定します。
[変更の保存] を選択して、更新を DB パラメータグループに保存します。
重要
default.mysql5.6、default.mysql5.7、または default.mysql8.0 DB パラメータグループを変更すると、そのパラメータグループを使用するすべての MySQL バージョン DB インスタンスに影響を与えます。AWS リージョン内の特定の MySQL 5.6、5.7 または 8.0 DB インスタンスに別のバイナリログ形式を指定する場合は、独自の DB パラメータグループを作成します。このパラメータグループで、別のログ形式を指定し、その独自の DB パラメータグループを目的の DB インスタンスに割り当てます。

Amazon RDS では、通常、バイナリログはできる限り早く消去されますが、mysqlbinlog によってアクセスされるバイナリログはインスタンスで保持される必要があります。RDS でバイナリログを保持する時間数を指定するには、mysql.rds_set_configuration ストアドプロシージャを使用して、ログのダウンロードするのに十分な期間を指定します。保持期間を設定したら、DB インスタンスのストレージ使用状況をモニタリングして、保持されたバイナリログに必要以上の容量が使用されないようにします。

binlog retention hours の最大値はMySQLの場合は168時間(7日)
https://qiita.com/kooohei/items/90a1ad7d3e83b1e941ec

MySQL 5.6
MySQL 5.7
MySQL 8.0
バイナリログの保持時間-> デフォルト値はNULL(保持しない)、5分程度で削除されてしまう
binlog retention hours の最大値はMySQLの場合は168時間(7日)　以下のコマンドで実行できる
call mysql.rds_set_configuration(‘binlog retention hours’, 24);
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/mysql_rds_set_configuration.html

Multi-AZ DB インスタンスをプロビジョニングすると、Amazon RDS はプライマリ DB インスタンスを自動的に作成するのと同時に、異なるアベイラビリティーゾーン (AZ) にあるスタンバイインスタンスにデータを複製

インフラストラクチャ障害の場合、Amazon RDS はスタンバイ (Amazon Aurora の場合はリードレプリカ) に自動的にフェイルオーバーするので、フェイルオーバーが完了するとすぐにデータベースの動作を再開できる

なるほど、そういう意味か。

同一リージョン内の独立したロケーション
障害発生時は自動でフェイルオーバーが行われ、1,2分で完了します。つまり、サービスが止まる時間はこのフェイルオーバーが行われている間だけなのでとても短い時間で済む。

リードレプリカの作成を押下すると、
– 送信先リージョン
– サブネットグループ
– アベイラビリティーゾーン
– 暗号化
– インスタンスの仕様

インスタンスのクラスも設定できる

レプリケーションロールがマスタとレプリカとなる。

CPU クレジット残高は、CPU 利用率がベースラインを上回り、前の 5 分間に消費したクレジットが獲得したクレジットよりも多かった場合に減少します。

-フェイルオーバーとは、稼働中のシステムで問題が生じてシステムやサーバーが停止してしまった際に、自動的に待機システムに切り替える仕組み

-HA機能ともいわれ、システムの可用性を高めるための冗長化.

Requiredなイベントについて、事前に知る必要がある。

なるほど、ここでサブネットとavailability zoneをchoiceするのね。

メンテナンスウィンドウの設定

なるほど♪

おおおおお、すげー

やけに時間かかるじゃねーか

ステータス　バックアップ中　ってどういうことだ？？
とりあえずこれ、vagrantから接続できるんだろうか。。。

vagrantからはつながらないようです。
[vagrant@localhost aws]$ mysql -u root -p -h rds-mysql-server.hoge.ap-northeast-1.rds.amazonaws.com
Enter password:
ERROR 2003 (HY000): Can’t connect to MySQL server on ‘rds-mysql-server.c7fqvxerfcrm.ap-northeast-1.rds.amazonaws.com’ (110)

>EC2インスタンスのセキュリティグループには、Amazon RDS for MySQLインスタンスのセキュリティグループ[example-rds-mysql-server]に対するMySQL接続許可を追加した[example-server]セキュリティグループを割り当てます。
これか！

インバウンドルール
そのセキュリティグループに関連付けられたインスタンスにアクセスできるトラフィックを規制するルール

[ec2-user@ip-hoge ~]$ mysql -u root -p -h rds-mysql-server.hoge.ap-northeast-1.rds.amazonaws.com
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 13
Server version: 5.7.22-log Source distribution

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql>

おおおおおおおおおおおおおおおおおおお、きたきたきたーーーーーーーーーー
セキュリティグループで若干手間取りましたがwww

サブネットグループの次はパラメーターグループをつくります。

パラメーターグループできました。

DBインスタンス

Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Serverがあります。なるほど。

ユースケース　開発/テストを選択する

DBインスタンスのクラス
db.t2.micro – 1 vCPU, 1 GiB RAM
20 GiB
概算月間コスト
21.74 USD

たけーな、なんでLinuxのEC2よりDBエンジンのコストの方が高くなるのかわからん。

まずセキュリティグループを作ります。

まずconsoleのログイントップ

Amazon RDS for MySQLインスタンス(MySQLバージョン5.6.27のMySQLデータベースサーバ)を作成し、Amazon EC2インスタンス(Amazon Linux)からMySQLデータベースへ接続して利用開始する

RDSサービス詳細
https://aws.amazon.com/jp/rds/
対象:Amazon Aurora, PostgreSQL, MySQL, MariaDB, ORACLE, SQL Server
MongoDBなどNo SQLはないのかな。。

まず、EC2からRDS用のセキュリティグループを作ります。

サブネットグループをつくる

abilability zoneを作る

ap-northeast-1a

この　ap-northeast-1a　ってよく出てくるな。

——–
Amazon EC2 は、世界各地のロケーションでホスティングされています。これらのロケーションは、リージョンとアベイラビリティーゾーンから構成されています。リージョンはそれぞれ、地理的に離れた領域です。1 つのリージョンに複数のそれぞれ独立したロケーションがあり、このロケーションを「アベイラビリティーゾーン」といいます。Amazon EC2 では、お客様がインスタンスなどのリソースとデータを複数のロケーションに配置できます。複数のリージョンにまたがってリソースのレプリケーションを行うには、お客様がそのように指定する必要があります。

リージョンでロケーションが異なるのね。

なるほど、東京と大阪か。
ap-northeast-1
アジアパシフィック (東京)
ap-northeast-2
アジアパシフィック (ソウル)
ap-northeast-3
アジアパシフィック (大阪: ローカル)

サブネットが出来ました。