AWSでRDS-oracle

oracleライセンス高いけど、awsでもoracle使える。

ec2ホストからoracle使わせたり、s3バケットに向かってデータポンプでのバックアップ取ったり。

rdsそのものを丸々バックアップするawsバックアップの指定もつけてく。

本体を作る前に、作成してくもんがあるから順に作る。

ポリシーとロールの設定

oracleデータポンプ用の出力先にnari-s3-bucketを作っておいて、rdsから使わせるポリシーを用意。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::nari-s3-bucket",
            "Resource": "arn:aws:s3:::nari-s3-bucket/*"
        }
    ]
}

作ったポリシーをロールにつける。

ロールには信頼関係つける。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "service": "rds.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

セキュリティグループの設定

セキュリティグループを作成する。許可対象のec2が複数あるから、ここではソースの指定にマネージドプレフィックスリスト使った。

アウトバウンドは省略するけど、他のホストからDBリンクとか作られたときのため、ほぼ全解放(0.0.0.0)しとく。

vpcの画面にあるマネージドプレフィックスリストにec2-windowsホストのIPやサブネットを指定しとく。

サブネットグループの作成

アベイラビリティーゾーンを指定してサブネットグループを作成。普通は指定１つでええ。

rdsでマルチにすると、１つのアベイラビリティーゾーンで障害起きても別のゾーンで自動起動できるから、意地でも起動してくる。

オプションループの作成

エンジンとバージョンの指定しとく。

オプションはたくさんあるけど、テスト環境で普段つけてるのは３つ。

Statspackは、Oracle社がデータベースの配布キットと共に提供するパフォーマンスチューニングキット。19cでも使ってる。

パラメータループの作成

パラメータグループも指定する。se2ってあるのはstandard-edition2かな。

本体作成

m5.xlargeあたりを選ぶ。

ホンマは100GBでもええ。データ流し込み前は小さく作っておいて、利用率に応じて後で広げる。自動スケールはやらん。

先に作っておいたセキュリティグループを使う。

バックアップを有効にする。バックアップウィンドウはUTC指定なのが面倒。期間は「0.5時間以内に開始」みたいな意味やったはず。

rdsだけやなくて、utc指定する箇所はawsに他にもある。時差変換は面倒やけど、計算してくれるサイトあるから常用。作者さんありがとう。

UTC/協定世界時とJST/日本標準時の変換と時差の計算 - 時差計算ドットコム

www.jisakeisan.com

ElastiCacheは使わんから、そのまま閉じる。ここから１５分ぐらい待たんと利用可能にならん。それでも手動でインストールして構築すること考えたら楽チン。

利用可能になった後、準備しといたロールを追加しとく。

接続確認とデータ流し込み

RDSにs3からデータを流し込める。

「Amazon S3 統合」 - Amazon Relational Database Service

docs.aws.amazon.com

データの準備とかは割愛するけど、接続確認を含めて実際にはこのへんでやってる。

AWSでs3バケット利用 | ギャバンITサービス

gavann-it.com

「一意制約違反」がボンボン出ることあるから、あんまりoracleのデータ流し込み作業好きやないんよな。

RDSのクセとか特性

aws-rdsは「いかにずっと稼働できるか」を追求してはるから金かかる。

お客さんによってはRDS使わずに、ec2ホストでDBMSインストールして稼働させることもある。

1. 完全停止できん。一時停止みたいなことしても、7日経過後にまた起動してくる
2. ダンプデータでのバックアップ・リストアはs3バケットを通じて使う
3. ダンプデータをs3バケットを通じて使うときはaws cliやなくて sqlでやる
4. ダンプデータはrds-oracleの中に残るから毎回削除しとかなディスクいっぱいになる(消し方忘れた)
5. マルチAZにしとくと、ゾーン障害とかあっても稼働に耐えるDBになる
6. rdsのエンドポイント名は恒久的やけど、IPは変わってくからtnsnames.oraにIPアドレス書いたらアカン
7. DB丸ごとバックアップがあるのでインフラ管理としてはかなり楽
8. オートスケールってのがあって容量を気にしなくて済む(青天井怖いなぁ)
9. メンテナンスウィンドウによってパッチ適用やバージョンアップができるけど、まれにコケてオフライン時間が長くなる

最後の「まれにコケてオフライン時間が長くなる」は、半日とか長すぎる時間経って起動してこんかったら、awsサポート窓口に直接言わんと解決せん。

aws側で監視して、気づいたら手動で現象回避してるらしいけど、これはツラい。

メンテナンスウィンドウはawsで管理してるから利用者側ではどうにもできん。

データベースをフルマネージドで使うのはなかなか難しいで。

というか、oracleでないとできんことが列挙できんかったら、ec2でpostgresqlやmariadb使ったほうがええんとちゃうか。