• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Rdsでうまくmysqldumpを取る
 

Rdsでうまくmysqldumpを取る

on

  • 162 views

AWS RDSに移行したけど

AWS RDSに移行したけど
* mysqldumpを寄せ集めたデータウェアハウスを運用している
* どうしてもmysqldumpをとりたい
となったとき

Statistics

Views

Total Views
162
Views on SlideShare
152
Embed Views
10

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 10

http://www.slideee.com 10

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Rdsでうまくmysqldumpを取る Rdsでうまくmysqldumpを取る Presentation Transcript

    • RDSでMYSQLDUMPをうまく取ってリストアする方法
    • あるある
    • 集計しやすい 別DBのデータもjoinできる 運用しやすい 本番DBに重いSQL投げたくない運用者    〃    投げててほしくない管理者 超最新データは無くてもいい 小~中規模なら常套手段…ですよね?
    • よくあるMYSQLDUMP
    • サービスで使っているslaveからmysqldump MyISAM mysqldump取得中のlock サービスに影響を与えない取得方法はお金がかかる LVMでsnap shotとってとかさ… dump用のslave用意してとかさ…
    • 一方、RDSは…
    • 最初のうちはMASTERDB1つで運用して インスタンスサイズ大きくしていって 参照がボトルネックになってきたら Read Replicaを用意するのがいい…らしい
    • SLAVEが無い 構成が多いのか…
    • どうしよう
    • …その前に。
    • RDS基礎知識 BACKUP WINDOW
    • Backup Window 毎日のバックアップの希望時間(UTC)を設定できる 指定時間の30分間の間にバックアップスナップショット が取得される
    • そうか!
    • スナップショットから 一時的にRDS作れば MYSQLDUMP取得できる!
    • 流れ
    • スナップショットから RDSを作る BASHスクリプト図の(2),(3)
    • https://github.com/imura81gt/aws- tools/blob/master/rds/restore-db-instance-from-db- snapshot.sh
    • RDSを削除する BASHスクリプト図の(5)
    • https://github.com/imura81gt/aws- tools/blob/master/rds/delete-db-instance.sh
    • 気をつけたこと
    • RDSにEnvタグを付ける スナップショットから作るRDSは「Env:backup」 IAM Policy Env:backup のRDSしか削除できないPolicy
    • 参照権限 { "Version": "2012-10-17", "Statement": [ { "Action": [ "rds:Describe*", "rds:ListTagsForResource", "ec2:DescribeAvailabilityZones", "ec2:DescribeVpcs", "ec2:DescribeAccountAttributes", "ec2:DescribeSecurityGroups" ], "Effect": "Allow", "Resource": "*" },
    • スナップショット権限 { "Action": [ "rds:RestoreDBInstanceFromDBSnapshot", "rds:CreateDBInstance" ], "Effect": "Allow", "Resource": "*" },
    • 更新、削除権限-Env:backupのRDSだけ { "Effect": "Allow", "Action": [ "rds:DeleteDBInstance", "rds:ModifyDBInstance", "rds:ModifyDBParameterGroup", "rds:ModifyDBSubnetGroup", "rds:CopyDBSnapshot", "rds:DownloadDBLogFilePortion", "rds:PromoteReadReplica", "rds:RebootDBInstance", "rds:RestoreDBInstanceFromDBSnapshot", "rds:RestoreDBInstanceToPointInTime" ], "Resource": "*", "Condition": { "streq": { "rds:db-tag/Env": [ "backup" ] } } } ] }
    • 良かったところ/悪かったところ
    • 良かったところ 本番環境RDSとは切り離された環境になるので… Master -Slave関係がないので、無理にMasterとインス タンスサイズを合わせる必要が無い Master : db.m3.large / backupRDS : db.t1.micro でも いい read replicaと違って、作成時に本番環境に負荷をかけ ないで済む
    • 悪かったところ 小額だがお金はやっぱりかかる スナップショットから作成するRDSのbackup windowを offにしたいけど、status:available のあとにmodifyしない とoffにできない status:creatingの後、status:backing-upがすぐ実行されて しまう IAMのテストをしっかりしないと、意図しないRDSを削 除しかねない バックアップ元RDSでinnodb_file_per_tableを有効にしち ゃうと、スナップショットからの作成が遅い
    • おわり