AR ホームベーカリー

オイラのアウトプット用ホームベーカリー！

EC2で既存インスタンスの移行をする時

memo

右クリックから「同様のものを作成する」か「イメージ」から作成して、AMIを指定して移行する。

beniyama.hatenablog.jp

スナップショットから作成しようとしてたんだけど、ずっと「不十分なデータです」とか言われて、なんじゃい！！って顔してた。 スナップショットから作成する時は、初期選択されている仮想化タイプがHVMじゃないので、インスタンスがHVMタイプの場合はそのあたりを注意しないといけないらしい。 僕は諦めて上記の通り、イメージを一度作成してから移行しました。

Elasticsearchのインデックスを確認する

今入ってるインデックスが何でどれくらいなのか確認したい時。

[root@localhost ~]# curl 'http://localhost:9200/_cat/indices?v'
health status index                                            pri rep docs.count docs.deleted store.size pri.store.size
yellow open   .kibana                                            1   1          3            1     23.6kb         23.6kb
yellow open   shakespeare                                        5   1     111396            0     18.9mb         18.9mb
yellow open   logstash-2015.05.20                                5   1       4750            0     28.5mb         28.5mb
yellow open   accounts                                           5   1       1000            0    442.6kb        442.6kb
yellow open   logstash-2015.05.18                                5   1       4631            0     27.2mb         27.2mb
yellow open   logstash-2015.05.19                                5   1       4624            0     28.3mb         28.3mb

データの投入とかはこのへん見つつやりました。

www.elastic.co

qiita.com

innodb_log_file_sizeを変更してもMySQLが文句を言わなくなった

MySQL memo

まじかよ知らなかったすげえっていう周回遅れの情報。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.5.7 InnoDB ログファイルの数またはサイズの変更、および InnoDB テーブルスペースのサイズの変更

MySQL 5.6.8 の時点では、InnoDB ログファイルの数またはサイズを変更する際に、innodb_fast_shutdown 設定が関連しなくなりました。さらに、古いログファイルを削除する必要もなくなりました。

お、まじか進化してんな。5.5以下で環境作る時、いつもinnodb_fast_shutdownしないでシャットダウンしてmy.cnf修正して起動させてエラーでib_data消してたからナー。

20160926追記

試しに5.7.15でinnodb_data_file_path変更してみたら、結局全部データ爆発してInnoDB見えなくなってデータベースのDropもできなくなってだめやんけ！！となりもうした。 作業前に作成したデータベースのバックアップ作成してたので事なきを得ましたが、やっぱ運用の最初から考慮してないのではだめなんすかねえ。

checking for tcutil.h... noとなったので

ゆえあってtokyocabinet-1.32.0をbundle installで導入しようとしたのだけれど、以下の様にエラーになった。

checking for tcutil.h... no

東京キャビネットをインストールしてやればbundle install通るらしい。

[root@localhost ~]# cd /usr/local/src
[root@localhost ~]# wget http://fallabs.com/tokyocabinet/tokyocabinet-1.4.48.tar.gz
[root@localhost ~]# tar -zxvf tokyocabinet-1.4.48.tar.gz
[root@localhost ~]# cd tokyocabinet-1.4.48
[root@localhost ~]# ./configure --prefix=/usr/local
[root@localhost ~]# make
[root@localhost ~]# make install

bundle installは通るようになったけどこれで良いのだろうか……？

assetの確認

memo Rails

今使ってるassetのdigestを確認する

consoleとかで実行すればよさそう。

Rails.application.assets.find_asset(asset_name).digest

blog.n-z.jp

指定したファイルのdigestを確認する

このようにしたらいいらしい。

Rails.application.assets['jquery'].digest

stackoverflow.com

possible SYN flooding on port XXXX. Sending cookies.

memo

慌てないのが一番です。 ぼくは徹夜でリリースなのと、前日夜に風邪を発症して全身が痛いでしゅ……。

Serverから応答がない！

httpの監視をしていたサービスが急遽failedを送信してきました。 そのサーバはいつも夜間のバックアップやバッチ実行時、よくスワップアウトして度々警告がくる環境です。 たぶんそんな環境もあるでしょう。

ここで慌てずdmesgです。

[root@localhost ~]# dmesg
...
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.

OOM Killerかと思いましたが違うようですね。3306といえばMySQLです。グローバルに開放はしていませんがどうしたのでしょう。プロセスの状態を確認してみます。

[root@localhost ~]# /etc/init.d/mysqld status
mysqld (pid 11451) is running...

動作していますね？ ではSYN floodingとはなんでしょう。以下の記述が参考になります。

小岩以上アキバ未満~記憶のディザスター~: CentOS6などでdmesgにpossible SYN flooding on port(SYN flooding警告)が出た場合の対策方法を考えてみるテスト

サーバーで受け付けられない（受け付けてない）SYNが大量に来た場合にサーバーがどうしたかを教えてくれている模様。

どこからかアタックを食らったのかもしれませんね。 MySQLのプロセスを再起動してみましょう。

[root@localhost ~]# /etc/init.d/mysqld stop
[root@localhost ~]# /etc/init.d/mysqld start

restartしないのはサーバのSWAPが9割食われてて一度失敗したからです。 これで再起動できた後しばらくおけば、正常にアクセスできるようになるはずです。