旧DBからdumpファイルを取得してRDSにインポートしようとしたら結構手間取った。 mysqldumpの実行 まずは旧環境にログインしてdumpファイルの出力 $ mysqldump -uuser_name -p -hhost_name --quick --single-transaction database_name > dump.sql
EBSでのProvisioned IOPS (以下 PIOPS) が出て、しばらくして RDSでも PIOPSに対応した。その後、RDSのIOPS上限が10,000から30,000に引き上げられた。 Amazon Web Services ブログ: 【AWS発表】Amazon RDS がスケールアップ! 3 TB、30,000 PIOPSまで拡張可能に され、これでRDSでIOPS30,000の性能が出る!とおもいきや、落とし穴(注意書き)が。 Factors That Affect Realized IOPS Rates 実際に出るIOPSは、ページサイズとネットワーク帯域に依存する。ページサイズはDBエンジン毎にきまっている。IOPSはDBインスタンスサイズやDBの負荷パターンにも影響をウケる。 DB EnginePage SizeMaximum IOPS Rate MySQL 16
Amazon Aurora 東京ローンチイベント 10/Nov/2015 発表資料 - RDS for MySQL から Aurora への移行に関する共有 事前に読んでおくべき資料 - Amazon re:Invent (DAT405) Amazon Aurora Deep Dive http://www.slideshare.net/AmazonWebServices/dat405-amazon-aurora-deep-dive - AWS Black Belt Tech Webinar シリーズ 2015 - Amazon Aurora http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2015-amazon-aurora - RDS for AuroraとRDS for MySQL5.6のPar
RDS のストレージを改めて見直すことで月 244 ドルのコストダウンに成功しました。特に目新しいことをしたわけではありませんが、昔から RDS を使っている人こそ盲点かもしれません。 RDS の 3 つのストレージ RDS のストレージは EBS と同じように 3 種類あります(Amazon RDS のストレージ)。 Magnetic (Standard) - standard General Purpose (SSD) - gp2 Provisioned IOPS - io1 これまでは Provisioned IOPS に 1000 IOPS を指定していました。 普段のワークロードはあまり高くないのですが、特定の機能で一時的に跳ね上がるため Provisioned IOPS を選択していました。 RDS に移行したときは General Purpose がまだ使えなかったので仕方な
事の発端 RDSで作成したmysqlで以下のコマンドを実行した所「UTC」である事が判明 mysql > SELECT date(); これはあかん。 ということで対策を取る。 とりあえず変更してみる。 SESSIONでTimeZoneをTokyoに変更する。 mysql > SET SESSION time_zone = ‘Asia/Tokyo’; するとTimeZoneが日本時間になることが判明する。 しかし問題があることがわかった。 ・再起動した場合に時間が「UTC」に変更される。 「SESSIONだからダメだよなー」と思って GLOBALでコマンドを実行した所、RDSはrdsadminユーザ以外出来なさそう。とのこと。 (詳しくは調べてないけど。) そのためSESSIONにての変更は再起動しない限定となる。。 次へ進む init_connectにストアドを突っ込む SESSIONは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く