kawakamasu備忘録スマートフォン用の表示で見るkawakamasu備忘録この広告は、90日以上更新していないブログに表示しています。Auroraに移行した際の振り返り。RDSはもとより、ほぼDBなど触ったことがなかったのでとてもいい経験になりました。Auroraに移行する。移行するデータは数百GB〜TBぐらい。本番を切り替える際のDB停止時間は可能な限り短くする。(数時間)オンプレで稼働しているDBのバックアップを取得して、Auroraにリストア。Aurora間でレプリケーションを貼り、タイミングを見計らって数時間の間で本番DBを切り替える。AWSのドキュメントにも方法が記載してあり、(容量にもよると思うが)リストアがmysqldumpよりも高速という理由でxtrabackupを選択。失敗して結局mysqldumpで移行することに。移行時に気をつけるポイントなどInnoDBが破損していないかチェックS3に置いたバックアップファイルからAuroraを起動した際に失敗したのでxtrabackupを使って移行する場合は確認した方が良さげ。InnoDB破損に気がつかず、結構な時間を無駄にした。チェックする際はMySQLの停止が必要。ファイルチェックサムユーティリティーAuroraは圧縮テーブルをサポートしないこれにハマった時点で圧縮テーブルのことすら知らなかった。Auroraはrow_formatが"Compressed"なテーブルはサポートしていない。Serviceドキュメント見逃してた。再度S3に上げなおすという方法をとった。移行元のサーバのDisk容量が逼迫してるとか、そういう時に。巨大なテーブルをリストアする際、セカンダリインデックスを後から作成する、という手法を使うとリストアが早くなる。テーブルの定義とデータを分けてdumpを取得したり、dumpしたファイルを書き換えるなど手間はかかる。参考にさせていただきました。Auroraでセカンダリインデックスを作成する場合はインスタンスサイズに注意。内部ストレージの容量以上の量のインデックスファイルを作ろうとすると、エラーが発生する。status"などで把握しておくと良い。Auroraのレプリケーションで更新されていくカラムの時刻がオンプレと9時間ズレていることが発覚。オンプレのシステム時刻がJSTで、Auroraのシステム時刻がUTCということから起きる現象。オンプレ側のシステム時刻を明示的にJST(Asia/Tokyo)にしておくことで回避できるはず。念のためbinlogの中身を確認してtimezoneが指定されていることを確認しておく。参考にさせていただきました。MySQLからAuroraへのユーザ移行MySQLとAuroraのユーザテーブル(mysql.user)の構造が違うため、dumpをそのままインポートとかはできない。Auroraには独自のカラムが追加されていたり、付与できない権限などあり、ハマった。Auroraにユーザ移行を行う場合は素直にパスワード情報など確認してからgrantコマンドで作るなどした方がよい。binlogを有効にしているとゼロダウンタイムパッチが効かないメンテナンスなどでAuroraに再起動などが走った際、セッションが切れないゼロダウンタイムパッチという機能がある。binlogを有効をしていると、この機能が使われないので注意が必要。フェイルオーバーした時にうっかり若干停止してしまった。01:15(いまさらだけど)teratermマクロで自動ログインTweet広告を非表示にするもっと読むコメントを書く2018-04-19CloudFront経由で静的ページをS3ウェブホスティングAWSやりたいことCloudFrontをたててS3にあるhtmlファイルを独自ドメインで見れるようにするこの構成をつくりたいhttp://aws.clouddesignpattern.org/index.php/CDP:Cache_Distribution%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3参考にしたページDevelopers.IO(クラメソさんの技術ブログ、いつもお世話になってます。superblock.起動ディスクなど、パーティション切られてるとちょっとめんどくさいみたい。dockerを使うAWSbeanstalk触り始めの時に理解に苦しんだので備忘録。"/usr/share/nginx/html"}]}jsonに馴染みがないので苦戦。今回はEC2で作ったファイルをbeanstalkのインスタンスにデプロイするという形。Linux上でmkdirでディレクトリを作って、それを丸ごとアップデートしてデプロイする感じ。Linuxからだとzipする必要がないらしい。create"コマンドで対話的に環境を作ることができるアップロードされたディレクトリは、beanstalk上のインスタンスの"/var/app/current"にアップされる。WordPress前回WordPressのインストールをした後の気づきです。WordPressの表示がおかしいAWS上のEC2インスタンスにテスト環境を作ったのですが、しばらく使わないだろうという理由で一旦シャットダウンしていました。その後、ちょっと確認したい事があったのでEC2を起動してWordPressにアクセスしたのですが、表示が壊れている状態となっていました。調べてみるとよくある現象のようですが、インストール時にパブリックIP直打ちでインストールした場合、WordPressのサイトアドレスに「http:(IPアドレス)」と設定されてしまい、EC2のシャットダウン、起動によりサーバのIPアドレスが変わってしまうため、諸々設定が読み込めず、サイトの表示が壊れてしまうようです。思い浮かんだ対処としては、以下2点。インストール後、EC2を落とさずにWordPressの設定からサイトアドレスを変更[設定]-[一般]-[サイトアドレス(URL)]を変更2.ドメイン設定してからインストール(今回はRoute53を使用)WordPressの管理画面から「更新」などができないAWS上だけに限った話ではないですが、インストールディレクトリの所有者をroot等にしている場合、更新する際にFTPの情報を求められると思います。今回の環境ではwebサーバはapacheを使っているので、インストールディレクトリ(/var/www/wordpress)の所有者をapacheにしてあげることで回避可能。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。