既存の静的ファイルはS3に移行【#np2020】

WordPress Logo

MovableTypeからWordPressに移行するにあたり、画像も移行しよう(MovableTypeの「アイテム」からWordPressの「メディア」へ)かと思いましたが、URLの切り替えが面倒すぎるし、メディアの中で収拾が付かなくなるのは火を見るより明らかなのであえて移行しないことに決めました。もちろんWordPressで新しく書く記事についてはWordPressのメディアを利用して管理しますが、既存記事の画像は全てAWS S3に入れてしまうことに。

続きを読む

【メモ】ローカルのMySQLにrootでログイン出来なくなったら

mysql_logo.png 動作確認のためにVagrant上にインストールしたMySQLにrootでログイン出来なくなってしまいました。

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
メインで使っていない開発環境の方なので、きちんとパスワードを設定したかも疑わしい。普段使っている限りではrootでログイン出来なくても別に困らないんですが、DBユーザーに十分な権限が割り当てられていなくて、テーブル作成すらできないことがわかったのでなんとかしないといけない。 仕方が無いので、次の手順でrootのパスワードを再設定し、ローカルホストからのアクセスに権限を付与したたところ、ログイン出来るようになりました。 (パスワードを設定したつもりでしてなかったのかも)

環境

  • CentOS 7
  • MySQL 5.6

手順

$  sudo vi /etc/my.cnf
mysqld に skip-grant-tables を追記
$ sudo service mysqld restart
$ mysql -u root
mysql > use mysql;
mysql > UPDATE `user` SET `authentication_string` = PASSWORD('password') WHERE `user` = 'root';
mysql > flush privileges;
mysql > grant all privileges on *.* to root@localhost identified by 'password' with grant option;
mysql > flush privileges;
mysql > quit
$ sudo vi /etc/my.cnf
skip-grant-tables を削除
$ sudo service mysqld restart
$ mysql -u root -p

嵌まった点

  • CentOS7で上手くMySQLをセーフモードで起動出来なかったので、my.cnfに追記しました。多分なんか方法があるはずです。
  • パスワードを設定したあと、権限の変更を行おうとしたら、skip-grant-tablesが設定されてるからダメだと怒られました。が、 flush privileges してから変更したら上手く出来ました。それでいいのか……
なにはともあれ、何とかログイン出来るようになってよかった。そもそも、ログイン用のユーザーに適切な権限を設定しておけばこんな面倒なことにはならなかったんですけどね。まあいいか。ローカルだし。

続きを読む

【メモ】Vagrant上のAdminerで「不正なCSRFトークン。再送信してください」エラー

adminer.png Vagrant上に入れたAdminerでデータベース操作をしようと思ったら以下のエラーが。

不正なCSRFトークン。再送信してください
まあセッションの権限に問題あるよねということで調べると、セッションディレクトリ「/var/lib/php/session」の権限は以下のようになってました。
Access: (0770/drwxrwx---)  Uid: (    0/    root)   Gid: ( 1000/ apache)
WordPressなど共有ディレクトリの権限問題を解決するために、このローカルサーバのApacheは、
User: vagrant
Group: vagrant
で動いています。 途中で変えたので、このセッションディレクトリのように権限が上手く行っていない場所があるんですね。なるほど。

続きを読む

【メモ】MySQLの「LIMIT 0, 1」と「LIMIT 1」

mysql_logo.png 結果の先頭から1件を取得する場合、手癖で「LIMIT 0, 1」と書いてしまいがちなんですが。

SELECT * FROM items LIMIT 0, 1;
これに対してレビューで「LIMIT 1 で良くないですか?」というコメントをいただく。
SELECT * FROM items LIMIT 1;
それで何か変わるって話は聞いたことはないけど、コメント貰ったので一応仕ドキュメントを確認。

続きを読む

昨日、一時的にサービスが落ちていました。

15時くらいにサーバの1つが突然繋がらなくなり、何かやっちまったのか(例えばデータベースへの過剰なアクセスとか)と思ってサーバを再起動してみたのだけど全然ダメでおろおろしていたら、しれっとこんな告知が出てました。

メンテナンス・障害情報・機能追加|さくらインターネット公式サポートサイト

平素よりさくらインターネットをご利用いただき、誠にありがとうござ います。 本日、ご提供サービスにおきまして、以下の通り障害が発生いたしました。 ご利用中のお客様には大変ご迷惑をおかけしておりますことを深くお詫び 申し上げます。

影響範囲 : さくらのVPS 1Gプランの一部 IPアドレスが下記の範囲のお客様 219.94.245.15 ~ 219.94.245.134 障害内容 : サーバに接続できなくなる障害が発生しました。 障害によりVPSの意図しない再起動が発生しました。
ああうん、ドンピシャだよさくらさん。 いままでここまでビシッとターゲットになったことが無かったのでちょっと驚きました。発生したのが15時20分で復旧したのが18時05分。何が原因か解らないけど(機材の故障かなぁ)さすがに3時間とめられるのはきついなー。まぁ、障害発生は仕方ないか。ただせめてメールでお知らせくらいして欲しいなーと思いました。障害情報をRSSで読むといっても、それを読むRSSリーダーが今障害が起きているサーバに載っていたので。 とりあえず、データに何の問題も無くて良かったです。やれやれ。

続きを読む

MySQLのスロークエリログをmysqldumpslowで解析してファイルに書き出し、ログをローテーションする

MySQLのチューニングに当たってスロークエリログを書き出すことは良くあります。設定によっては放っておくと膨大なログになってしまうため、適度なタイミング(日毎とか週毎とか)でログローテーションしてやります。logrotateを使うのが常套手段。 スロークエリログの解析にはmysqldumpslowを使用します。mysqldumpslowを使用するとログを解析した上で、オプションに従って並べ替えて出力してくれます。ログ全体のまとめになるので、定期的これを実行すれば、どれくらいの頻度でスロークエリが発生しているかを定量的に計ることが出来ます。 …というわけで、この2つを組み合わせてみました。

/etc/logrotate.d/mysql

/var/log/mysql-slow.log {
# create 600 mysql mysql
notifempty
daily
rotate 5
missingok
prerotate
EXT=`/bin/date +%Y%m%d`
/usr/bin/mysqldumpslow -s t /var/log/mysql-slow.log > /var/log/mysql/mysql-slow.${EXT}.log
endscript
postrotate
# just if mysqld is really running
if test -x /usr/bin/mysqladmin && \
/usr/bin/mysqladmin ping &>/dev/null
then
/usr/bin/mysqladmin flush-logs
fi
endscript
}

続きを読む