技術者の備忘録

【ゆっくり】WordPress構築動画【AWS】

2020-02-24T00:47:00.002+09:00

動画で使ったコマンドの流れ

注意：動画の中で作成したEC2インスタンスはインターネットに面した構成になっています。

セキュリティグループで制限を掛けたとは言え、何があるか分からないので、

ひとしきり楽しんだ後は忘れずに停止or終了することを心がけてください。

1,既存パッケージのアップデート

$ sudo su -
# yum update

2,Apacheのインストール

# yum install httpd

3,PHP7.3のインストール

# amazon-linux-extras install php7.3

4,mariadbのインストール

# yum search mariadb | more
# yum install mariadb.x86_64 mariadb-server.x86_64 mariadb-devel.x86_64 mariadb-libs.x86_64

5,Apacheとmariadbの起動

# systemctl start httpd
# systemctl start mariadb

6,mariadb上の作業

6-1,ログイン

# mysql -uroot -p

6-2,データベース作成

mysql> create database wordpress;

6-3,ユーザー作成＆確認

mysql> grant all on *.* to wpuser@localhost identified by 'wppasswd';
mysql> select user, host from mysql.user;

6-4,ユーザー権限の適用

mysql> flush privileges;

6-5,作成したデータベースの確認

mysql> show databases;

7,wordpress用ユーザーとパスワードでのDB接続確認

# mysql -uwpuser -pwppasswd

8,WordPressの解凍と設置

# mv /var/www/html{,_old}
# cd ~ec2-user/
# tar zxf wordpress-5.3.2-ja.tar.gz
# mv wordpress /var/www/html
# chown apache:apache -R html

以上です。

MySQL8 vs MySQL5.6

2018-11-16T19:47:00.003+09:00

やりたいこと

MySQL5.6.40 vs MySQL8.0.11 の兄弟対決。
遅れ馳せながらMySQL8をベンチマークする。
RDSで選択可能な8.0.11に対するは、RDSのデフォルトでカーソルが合わさっている5.6.40。
セキュリティアップデート諸々含めて、5.6系では5.6.36の次に多いのではないかと勝手に想像して、このバージョンで戦っていきたいと思います。

検証環境

A,負荷試験をかける側

EC2 t2.micro
OS AmazonLinux1
ツール sysbench 1.0.15

B,負荷試験をかけられる側１

RDS db.t2.medium
MySQL MySQL5.6.40(RDSデフォルトバージョン)

C,負荷試験をかけられる側２

RDS db.t2.medium
MySQL MySQL8.0.11

お手軽環境準備

1,負荷試験をかける側の環境構築(MySQL5.6.40用)

epelを入れて
# yum -y install epel-release.noarch

mysqlクライアントと、sysbenchのインスト―ル
# yum -y install sysbench mysql56.x86_64
※AmazonLinux2の場合、MySQLライブラリの影響でsysbenchがyumですんなりインストールできないため、1を採用してます

2,負荷試験をかける側の環境構築(MySQL8.0.11用)

# cd /usr/local/src
# wget http://repo.mysql.com/yum/mysql-8.0-community/el/6/x86_64/mysql-community-client-8.0.13-1.el6.x86_64.rpm
# wget http://repo.mysql.com/yum/mysql-8.0-community/el/6/x86_64/mysql-community-common-8.0.13-1.el6.x86_64.rpm
# wget http://repo.mysql.com/yum/mysql-8.0-community/el/6/x86_64/mysql-community-libs-8.0.13-1.el6.x86_64.rpm
# yum install mysql-*.rpm
# mysql --version
mysql Ver 8.0.13 for Linux on x86_64 (MySQL Community Server - GPL)
※せっかくなので、MySQLClientも5.6→8.0に変更する

負荷試験をかけられる側の環境構築

1,RDSコンソールからMySQL5.6.40を起動

2,RDSコンソールからMySQL8.0.11を起動

3,RDSに接続

# mysql -uroot -p -h<RDS エンドポイント>
password:<自分で決めた任意のpassword>
※RDSのセキュリティグループの仕組みが変わり、セキュリティグループを接続元のセキュリティグループに割り当てる事ができるようになってました。
　EC2側の負荷試験を賭ける側のサーバのセキュリティグループからの3306を許可してあげてください。

4,DB作成・ユーザー作成・権限付与
※5.6系と8系でユーザー管理方法が若干変わったため、以下手順を併記

4-1,MySQL5.6.40用のコマンド

mysql> CREATE DATABASE sbtest;
mysql> GRANT ALL ON sbtest.* TO 'sbtest'@'%' IDENTIFIED BY 'sbtest';
mysql> exit
※sysbenchテスト用のユーザー・パスワードをsbtest:sbtestとしました。

4-2,MySQL8.0.11用のコマンド

mysql> CREATE DATABASE sbtest;
mysql> create user 'sbtest'@'%' identified by 'sbtest';
mysql> grant all privileges on sbtest.* to 'sbtest'@'%';
※ユーザーと権限付与を同時にできなくなったため、最初にユーザーを作成し、その後権限を付与するという流れになったようです。
※sysbenchテスト用のユーザー・パスワードをsbtest:sbtestとしました。

負荷試験用のテーブルを作成する

# sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--table-size=1000000 \
--mysql-host=<RDS エンドポイント> \
--mysql-password=sbtest \
--time=60 \
--db-ps-mode=disable \
prepare
※table-sizeは1,000,000レコード想定という意味らしく、容量ではない模様

負荷試験実施

# sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--table-size=1000000 \
--mysql-host=<RDS エンドポイント> \
--mysql-password=sbtest \
--time=60 \
--db-ps-mode=disable \
--threads=[同時処理数] \
run
※threadsの値を1,2,4,8,16,32と変更して実施

結果

レイテンシーを95パーセンタイルで集計した際の数値

60秒で処理したトランザクション数

所感

過去4系→5系の時も伝統的にそうですが、バージョンを上げるとパフォーマンスが落ちる傾向がありますね。今回はRDSの吊るしの設定のままなので、チューニングをすることで結果が覆る可能性も大いにあります。旧バージョンのMySQLのセキュリティアップデートスケジュールとの兼ね合いで、バージョンアップもしくは、別のRDBエンジンを選定していった方がいいと思いました。

おわり。

EFS導入で夢が広がると思ったら、現実を突き付けられた話

2018-11-12T12:49:00.002+09:00

EFS導入で夢が広がると思ったら、現実を突き付けられた話(※小規模構成に限る？)

** やりたかったこと
-- 今の構成の問題点

1,コンテンツの更新がそこそこ頻繁なため過去のAMIが使えず、負荷が上昇してからAMIを取得しているとバーストに対応できない
2,WEBの台数が多いサービスのコンテンツ更新の度にリポジトリサーバが高負荷になり、サーバごとに遅延が発生する。

-- EFS導入で期待したこと

1,上記問題点を解決できる。
2,念願の簡単な手順でのオートスケーリングが実現する。

** できなかった理由
-- EFSが遅い

コンテンツの更新にものすごい時間がかかるため、突発的なメンテナンスやバグ対応に支障をきたす。
※下記結果参照

-- EBSの場合

$ time svn st /ebs_content_dir
============================================
real 0m0.331s
user 0m0.207s
sys 0m0.100s
→はやい
============================================

-- EFSの場合

$ time svn st /efs_content_dir
============================================
real 2m59.950s
user 0m0.902s
sys 0m2.189s
→えぇ……。
フォーラムを確認してみたところ、fs-cacheをインストールしてマウントオプションに追加しろとの書き込みを発見
============================================

-- EFSの場合 with fs-cache有効化

$ time svn st dev_gm_shq_geso
============================================
real 1m38.342s
user 0m0.584s
sys 0m1.496s
→すごい！二倍早くなった！ってなるかい
============================================

-- その他フォーラムで情報を漁るものの……(意訳)

Aさん -- Nginx+WordpressでドキュメントルートをEFSにしたけどEBSに比べて2-7秒遅延するのだが？
Bさん -- おれも1-2秒は遅延してるわ。この遅延は最も優先すべき課題なので解決しない限り使うべきではないな。
Cさん -- 容量によって書込速度が変わるから、1TBのダミーファイル置くといいよ。金かかるけど。
2016年の北アメリカリージョンのサービス開始時に建てられたフォーラムスレッドが今もやり取りを続けている模様

** まとめ

1, サービス紹介のような最小構成でEFSを利用する場合は、コンテンツ配布およびWEBアクセスで数秒以上の遅延は覚悟する必要があります。
2, 大容量のNFSを利用する大規模顧客で、EC2+NFSで冗長性が不安だと思っている人向けのサービスみたいです。
3, もしくはあまりコンテンツの更新がなく、アクセスが遅くとも問題の無いサービス向けかと。

xtrabackupをつかったダンプリストア

2018-09-10T18:29:00.000+09:00

xtrabackupをつかったダンプリストア

** バックアップ方針

以下のファイルのダンプレストアを実施すると過程します

DBUser：root
DBPass：なし
DBHost：localhost
フルダンプ:/home/taterole/fulldump/2018-01-01-1
差分ダンプ:/home/taterole/increment/2018-01-02-1
差分ダンプ:/home/taterole/increment/2018-01-03-1
差分ダンプ:/home/taterole/increment/2018-01-04-1
差分ダンプ:/home/taterole/increment/2018-01-05-1
差分ダンプ:/home/taterole/increment/2018-01-06-1

** 事前に確認
- openfilesの確認をしておく

# ulimit -n
======================================================
1024
======================================================
■DB数がすると、デフォの1024では"too many open files"が出るかも

- /etc/security/limits.confに追記
-- バックアップ

# cp -pi /etc/security/limits.conf{,.`date +%Y%m%d`}

-- ２行追記

# sed -i \
-e '/student - maxlogins/a *\t\tsoft\tnofile\t\t8192' \
-e '/student - maxlogins/a *\t\thard\tnofile\t\t8192' \
limits.conf
======================================================
#ftp hard nproc 0
#@student - maxlogins 4 ← この行の下に
* soft nofile 8192 ← ソフトリミット8192
* hard nofile 8192 ← ハードリミット8192
======================================================

-- 差分

# diff /etc/security/limits.conf{.`date +%Y%m%d`,}
======================================================
--- /etc/security/limits.conf.YYYYMMDD YYYY-MM-DD XX:XX:XX.000000000 +0900
+++ /etc/security/limits.conf YYYY-MM-DD XX:XX:XX.000000000 +0900
@@ -57,5 +57,7 @@
#@faculty hard nproc 50
#ftp hard nproc 0
#@student - maxlogins 4
+* soft nofile 8192
+* hard nofile 8192

# End of file
======================================================
■こんな感じで2行追記されてるはず

** バックアップ方法
- フルダンプ

# xtrabackup --user=root --backup --galera-info --target-dir=/home/taterole/fulldump/2018-01-01-1 --no-lock

- 差分バックアップ(初回)

# xtrabackup --user=root --backup --galera-info --target-dir=/home/taterole/increment/2018-01-02-1 --incremental-basedir=/home/taterole/fulldump/2018-01-01-1 --no-lock
■初回差分バックアップは、--incremental-basedirにフルダンプの取得先を指定

- 差分バックアップ(二回目以降)

# xtrabackup --user=root --backup --galera-info \
--target-dir=/home/taterole/increment/2018-01-03-1 \
--incremental-basedir=/home/taterole/increment/2018-01-02-1 --no-lock
# xtrabackup --user=root --backup --galera-info \
--target-dir=/home/taterole/increment/2018-01-04-1 \
--incremental-basedir=/home/taterole/increment/2018-01-03-1 --no-lock
# xtrabackup --user=root --backup --galera-info \
--target-dir=/home/taterole/increment/2018-01-05-1 \
--incremental-basedir=/home/taterole/increment/2018-01-04-1 --no-lock
# xtrabackup --user=root --backup --galera-info \
--target-dir=/home/taterole/increment/2018-01-06-1 \
--incremental-basedir=/home/taterole/increment/2018-01-05-1 --no-lock
■二回目移行の差分バックアップは、--incremental-basedirに前回の差分バックアップの取得先を指定する

** 復旧データの結合作業
- ベースダンプファイルのプリペア

# xtrabackup --user=root --prepare --apply-log-only --target-dir=/home/taterole/fulldump/2018-01-01-1

- ベースダンプファイルに差分ダンプを結合しプリペア(ベースにどんどん古い順から結合を行っていきます)

# xtrabackup --user=root --prepare --apply-log-only \
--target-dir=/home/taterole/fulldump/2018-01-01-1 \
--incremental-dir=/home/taterole/increment/2018-01-02-1
# xtrabackup --user=root --prepare --apply-log-only \
--target-dir=/home/taterole/fulldump/2018-01-01-1 \
--incremental-dir=/home/taterole/increment/2018-01-03-1
# xtrabackup --user=root --prepare --apply-log-only \
--target-dir=/home/taterole/fulldump/2018-01-01-1 \
--incremental-dir=/home/taterole/increment/2018-01-04-1
# xtrabackup --user=root --prepare --apply-log-only \
--target-dir=/home/taterole/fulldump/2018-01-01-1 \
--incremental-dir=/home/taterole/increment/2018-01-05-1
# xtrabackup --user=root --prepare --apply-log-only \
--target-dir=/home/taterole/fulldump/2018-01-01-1 \
--incremental-dir=/home/taterole/increment/2018-01-06-1
■差分ファイルが複数ある場合は、古い順に結合を実施

** 全体リストア(MySQLの停止が必要)
- MySQLの停止

# service mysql stop

- MySQLディレクトリをリネーム

# mv /var/lib/mysql{,_bkup}

- 結合済みのディレクトリをMySQLディレクトリに戻す

# xtrabackup --copy-back --target-dir=/home/taterole/fulldump/2018-01-01-1

- 所有者の変更

# chown -R mysql:mysql /var/lib/mysql

- MySQLの起動

# service mysql start

** データベース個別リストア(データベースへの書き込みがないことを確認した後に作業を行う) [#w56ddd8d]
- MySQLの停止(絶対にアクセスが無い自信があればオンラインで可能でした)

# service mysql stop

- 既存のデータベースファイル格納ディレクトリを移動

# mv /var/lib/mysql/cool_ranko_db /tmp/cool_ranko_db

- 結合済みのバックアップファイルから対象のデータベースディレクトリを、mysqlのディレクリに移動

# rsync -av /home/taterole/fulldump/2018-01-01-1/cool_ranko_db /var/lib/mysql/

- 権限及びパーミッションの変更を行う

# chown -R mysql:mysql /var/lib/mysql/cool_ranko_db && chmod 700 cool_ranko_db

- MySQLの起動

# service mysql start

** 補足
- フルと差分どっちがいいのか

大量のデータベースをダンプする場合、
時間：差分ダンプ＞フルダンプ
容量：フルダンプ＞差分ダンプ
となります。

リストアする場合は、結合等の手間を含めると当然
時間：フルダンプ＞差分ダンプ
となりますので、容量が許すのであればフルダンプで都度取得しておくのがいいかもしれません。

- なぜinnobackupexを使わずxtrabackupを使うのか

バージョンアップした際にラッピングされたコマンドは、変更点がわかりにくいという欠点があるためです
それとどこかのアメリカ語のコミュニティで未来のバージョンでinnodbbackupexはなくなるよ。的な
発言を見た気がするからです(ソース失念…夢かも)

** おわり

再起動後にCentOS7でHTTPD2.4が起動しなくなる問題

2018-08-13T13:48:00.002+09:00

起こる事象
自動起動を設定したはずなのに、サーバ再起動後にHTTPD2.4が起動しない
ジャーナルを確認しても権限？何の？という状態に陥る

-- Unit httpd.service has failed.
--
-- The result is failed.
8月 13 12:00:26 azitovb56.azito.co.jp systemd[1]: Unit httpd.service entered failed state.
8月 13 12:00:26 azitovb56.azito.co.jp systemd[1]: httpd.service failed.
8月 13 12:00:26 azitovb56.azito.co.jp polkitd[606]: Unregistered Authentication Agent for unix-proclines 2160-2173/2173
8月 13 12:00:26 azitovb56.azito.co.jp systemd[1]: httpd.service: main process exited, code=exited,
8月 13 12:00:26 azitovb56.azito.co.jp kill[1490]: kill: cannot find process ""
8月 13 12:00:26 azitovb56.azito.co.jp systemd[1]: httpd.service: control process exited, code=exite
8月 13 12:00:26 azitovb56.azito.co.jp systemd[1]: Failed to start The Apache HTTP Server.

原因
systemdにて/var/run配下がtmpfsになったことが原因

再発試験

yumからHTTPD2.4をインストール
インストール過程で/var/run/httpdが作成される
HTTPD2.4を起動すると、/var/run/httpdの下にPIDが作成される
無事起動して気分良く動作確認する
サーバ再起動する
再起動時に/var/run/httpdが削除される
PIDが作成できなくなり、自動でも手動でも起動できなくなて慌てる

解決法
/usr/lib/tmpfiles.d/httpd.conf の内容を書き換えることで、再起動時にディレクトリが

任意の権限で作成され、HTTPD2.4が起動するようになる。

書き換え前
d /run/httpd 710 root apache
d /run/httpd/htcacheclean 700 apache apache
書き換え後
d /var/run/httpd 710 root apache
d /var/run/httpd/htcacheclean 700 apache apache

以前に一度同じハマりをした記憶があったのに、まんまと同じハマり方をしてしまったので、備忘を兼ねて公開いたします。

おわり

年末RDSメンテナンスでハマった件

2017-12-25T22:32:00.003+09:00

12/13～1/4で予定されているRDSのメンテナンスについてです

余計な事をした結果なのか、サンタさんからのプレゼントなのか判断できませんが、

がっちりハマったのでログを残します。

久しぶりの更新で心が痛い。

やりたかったこと：

年末年始にRDSのメンテナンスが予定されて居たため、コレを機にMySQLのマイナーバージョンアップと、Timezoneをスマートにする

できたこと：
MySQLのマイナーバージョンアップ(5.6.37になりました)

できなかったこと：
Timezoneをスマートにできなかった

何があったのか：
メンテナンスウインドウによる自動アップデートではなく、事前にメンテナンス時間を決めて、対応を行いたかったので、どうすればいいのかサポートに問い合わせたところ、
「インスタンスタイプを変更すれば今回のメンテナンス要件を満たせますよ。リブートだけじゃダメ。」
との提案をいただきました。

上記対応を完了し、少人数で動作確認を実施しサービスイン。
10分後くらいに凄まじくConnectionが滞留し、インスタンスが再起動を頻発しサービス停止・・・。

何が原因なのかサポートに問い合わせるも、いまいち原因がつかめないため、MySQLのバージョンアップ以外の要素を切り戻し、様子見すると負荷が落ち着いている。

ということで、Timezoneをストアド・プロシージャで設定する旧来の方法と、パラメータグループで設定するスマートな方法を比較して見ることにしました。

sysbenchで負荷試験を掛けてみる：
以下の3パターン
1,ストアド・プロシージャ設定有り(init_connect有り＋プロシージャ残し)＋Timezone設定無し
2,ストアド・プロシージャ設定有り(init_connect無し＋プロシージャ残し)＋Timezone設定Asia/Tokyo
3,ストアド・プロシージャ設定無し(init_connect無し＋プロシージャ削除)＋Timezone設定Asia/Tokyo
基本的には、パラメータグループのinit_connectの設定で、ストアド・プロシージャを呼ばないはずなので、2と３はほぼおなじ結果になるはず。

結果：
1のパターン：

SQL statistics:
queries performed:
read: 13818
write: 3948
other: 1974
total: 19740

2,3のパターン：

Initializing worker threads...
FATAL: Worker threads failed to initialize within 30 seconds!

ということで、Timezoneの設定をパラメーターグループに任せた場合なぜかパフォーマンスが落ちました。

サポートにベンチ結果を含めて緊急障害でアラートを上げていますが、多分次回メンテには間に合わない気がする…。

あまり居ないとは思いますが、同じように色々と一緒に対応しようとしている人は気をつけてください。

おまけ：
今回のRDSメンテナンスでAWS側がやった作業

2017-12-25 04:17:02 Looking for 'mysql' as: /rdsdbbin/mysql/bin/mysql
2017-12-25 04:17:02 Looking for 'mysqlcheck' as: /rdsdbbin/mysql/bin/mysqlcheck
2017-12-25 04:17:02 Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/tmp/mysql.sock' '--socket=/tmp/mysql.sock'
2017-12-25 04:17:02 Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/tmp/mysql.sock' '--socket=/tmp/mysql.sock'
2017-12-25 04:17:02 mysql.columns_priv OK
2017-12-25 04:17:02 mysql.db OK
2017-12-25 04:17:02 mysql.event OK
2017-12-25 04:17:02 mysql.func OK
2017-12-25 04:17:02 mysql.general_log OK
2017-12-25 04:17:02 mysql.general_log_backup OK
2017-12-25 04:17:02 mysql.help_category OK
2017-12-25 04:17:02 mysql.help_keyword OK
2017-12-25 04:17:02 mysql.help_relation OK
2017-12-25 04:17:02 mysql.help_topic OK
2017-12-25 04:17:02 mysql.host OK
2017-12-25 04:17:02 mysql.innodb_index_stats OK
2017-12-25 04:17:02 mysql.innodb_table_stats OK
2017-12-25 04:17:02 mysql.ndb_binlog_index OK
2017-12-25 04:17:02 mysql.plugin OK
2017-12-25 04:17:02 mysql.proc OK
2017-12-25 04:17:02 mysql.procs_priv OK
2017-12-25 04:17:02 mysql.proxies_priv OK
2017-12-25 04:17:02 mysql.rds_configuration OK
2017-12-25 04:17:02 mysql.rds_global_status_history OK
2017-12-25 04:17:02 mysql.rds_global_status_history_old OK
2017-12-25 04:17:02 mysql.rds_heartbeat2 OK
2017-12-25 04:17:02 mysql.rds_history OK
2017-12-25 04:17:02 mysql.rds_replication_status OK
2017-12-25 04:17:02 mysql.rds_sysinfo OK
2017-12-25 04:17:02 mysql.servers OK
2017-12-25 04:17:02 mysql.slave_master_info OK
2017-12-25 04:17:02 mysql.slave_relay_log_info OK
2017-12-25 04:17:02 mysql.slave_worker_info OK
2017-12-25 04:17:02 mysql.slow_log OK
2017-12-25 04:17:02 mysql.slow_log_backup OK
2017-12-25 04:17:02 mysql.tables_priv OK
2017-12-25 04:17:02 mysql.time_zone OK
2017-12-25 04:17:02 mysql.time_zone_leap_second OK
2017-12-25 04:17:02 mysql.time_zone_name OK
2017-12-25 04:17:02 mysql.time_zone_transition OK
2017-12-25 04:17:02 mysql.time_zone_transition_type OK
2017-12-25 04:17:02 mysql.user OK
2017-12-25 04:17:02 Running 'mysql_fix_privilege_tables'...

こういう事が「12月 25 1:19 午後 Database instance patched」の中で行われていたみたいです。

内容が全くかかれていなかったため、気になるかたはチェックしてみてください。

サポートからの連絡を待ちつつ、メリークリスマス。

2017/12/26追記：
MySQL5.6.34で「3,ストアド・プロシージャ設定無し(init_connect無し＋プロシージャ削除)＋Timezone設定Asia/Tokyo」のベンチも取得してみた。
Timeoutにならず、ベンチが普通に完了。

SQL statistics:
queries performed:
read: 8540
write: 2440
other: 1220
total: 12200

・・・・・・MySQL5.6.37とTimezoneのあわせ技が原因・・・？

AWS NAT Gatewayがつながらなくて嵌った件

2015-12-24T17:49:00.003+09:00

AWS NAT Gatewayのリリース

これでNATサーバが不要になってコスト削減も楽勝とウキウキしていたが・・・
結果ネットワーク設定の段で結構嵌ったので、設定内容の備忘録的な感じで

** 資料

slideshareを使ってみました。
詳細は以下をみてください。
http://www.slideshare.net/laporz/aws-nat-gateway-testjapanese

----

かきたいことは上記に全部書いたので、おしまい・・・

ベンチマークシリーズ Aurora vs MySQL 結果まとめ

2015-08-12T20:33:00.005+09:00

* ベンチマークシリーズ Aurora vs MySQL 結果まとめ

** 結果比較
- Connection数別トランザクション/分

Conn Aurora MySQL
20 6279.833 TpmC 6829.467 TpmC
30 8390.400 TpmC 1374.767 TpmC
50 11216.900 TpmC 1913.100 TpmC
70 14481.650 TpmC 2498.600 TpmC
100 14155.450 TpmC 2253.400 TpmC (詳細結果紛失
200 14932.350 TpmC ------- TpmC

- 所感

データ投入や20Connくらいの接続数の場合、MySQLの方に分があったけれど、Conn数を増やしていくと、
Auroraがリニアにスコアを伸ばし、限界値が高いようです
※両方パラメータは吊るしの状態なためチューニングすればまた違った結果になると思われます。

- 気になった点

・初期データ投入がMySQLは8時間で終了したところ、Auroraは15時間必要だった
・MySQL側のRDSインスタンスが、30Conn以上の時にCPU使用率が15%くらいで頭打ち、スペックを活かせていないようだった

- さいごに

本番想定のベンチマークを行ったため、生かしておくとお金が吸い取られるので
一旦バックアップを取ってココで終了。。。

----
以下は見たい人用の細々したやつです

** MySQLの結果
# ./tpcc_start -h 172.30.1.123 -P 3306 -d tpcc -u root -p coingame -w 50 -c 20 -r 180 -l 3600 -f ./mysql_tpcc.log

=================================================
<Raw Results>
[0] sc:409768 lt:0 rt:0 fl:0
[1] sc:409661 lt:0 rt:0 fl:0
[2] sc:40977 lt:0 rt:0 fl:0
[3] sc:40973 lt:0 rt:0 fl:0
[4] sc:40980 lt:0 rt:0 fl:0
in 3600 sec.

<Raw Results2(sum ver.)>
[0] sc:409774 lt:0 rt:0 fl:0
[1] sc:409766 lt:0 rt:0 fl:0
[2] sc:40977 lt:0 rt:0 fl:0
[3] sc:40973 lt:0 rt:0 fl:0
[4] sc:40980 lt:0 rt:0 fl:0

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.47% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

<TpmC>
6829.467 TpmC
=================================================

# ./tpcc_start -h 172.30.1.123 -P 3306 -d tpcc -u root -p coingame -w 50 -c 30 -r 180 -l 3600 -f ./mysql_tpcc_30.log

=================================================
<Raw Results>
[0] sc:82486 lt:0 rt:0 fl:0
[1] sc:82299 lt:0 rt:0 fl:0
[2] sc:8249 lt:0 rt:0 fl:0
[3] sc:8247 lt:0 rt:0 fl:0
[4] sc:8249 lt:0 rt:0 fl:0
in 3600 sec.

<Raw Results2(sum ver.)>
[0] sc:82486 lt:0 rt:0 fl:0
[1] sc:82487 lt:0 rt:0 fl:0
[2] sc:8249 lt:0 rt:0 fl:0
[3] sc:8248 lt:0 rt:0 fl:0
[4] sc:8249 lt:0 rt:0 fl:0

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.42% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

<TpmC>
1374.767 TpmC
=================================================

# ./tpcc_start -h 172.30.1.123 -P 3306 -d tpcc -u root -p coingame -w 50 -c 50 -r 180 -l 3600 -f ./mysql_tpcc_50.log

=================================================
<Raw Results>
[0] sc:114786 lt:0 rt:0 fl:0
[1] sc:114741 lt:0 rt:0 fl:0
[2] sc:11479 lt:0 rt:0 fl:0
[3] sc:11478 lt:0 rt:0 fl:0
[4] sc:11479 lt:0 rt:0 fl:0
in 3600 sec.

<Raw Results2(sum ver.)>
[0] sc:114788 lt:0 rt:0 fl:0
[1] sc:114791 lt:0 rt:0 fl:0
[2] sc:11479 lt:0 rt:0 fl:0
[3] sc:11478 lt:0 rt:0 fl:0
[4] sc:11479 lt:0 rt:0 fl:0

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.47% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

<TpmC>
1913.100 TpmC
=================================================

# ./tpcc_start -h 172.30.1.123 -P 3306 -d tpcc -u root -p coingame -w 50 -c 75 -r 180 -l 3600 -f ./mysql_tpcc_75.log

=================================================
<Raw Results>
[0] sc:149916 lt:0 rt:0 fl:0
[1] sc:149867 lt:0 rt:0 fl:0
[2] sc:14991 lt:0 rt:0 fl:0
[3] sc:14990 lt:0 rt:0 fl:0
[4] sc:14989 lt:0 rt:0 fl:0
in 3600 sec.
<Raw Results2(sum ver.)>
[0] sc:149916 lt:0 rt:0 fl:0
[1] sc:149914 lt:0 rt:0 fl:0
[2] sc:14991 lt:0 rt:0 fl:0
[3] sc:14991 lt:0 rt:0 fl:0
[4] sc:14990 lt:0 rt:0 fl:0
<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.47% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]
<TpmC>
2498.600 TpmC
=================================================

** Auroraの結果
# ./tpcc_start -h 172.30.2.234 -P 3306 -d tpcc -u root -p coingame -w 50 -c 20 -r 180 -l 3600 -f ./aurora_tpcc_20.log

=================================================
<Raw Results>
[0] sc:376790 lt:0 rt:0 fl:0
[1] sc:376635 lt:0 rt:0 fl:0
[2] sc:37679 lt:0 rt:0 fl:0
[3] sc:37679 lt:0 rt:0 fl:0
[4] sc:37679 lt:0 rt:0 fl:0
in 3600 sec.

<Raw Results2(sum ver.)>
[0] sc:376801 lt:0 rt:0 fl:0
[1] sc:376801 lt:0 rt:0 fl:0
[2] sc:37679 lt:0 rt:0 fl:0
[3] sc:37681 lt:0 rt:0 fl:0
[4] sc:37679 lt:0 rt:0 fl:0

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.47% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

<TpmC>
6279.833 TpmC
=================================================

# ./tpcc_start -h 172.30.2.234 -P 3306 -d tpcc -u root -p coingame -w 50 -c 30 -r 180 -l 3600 -f ./aurora_tpcc_30.log

=================================================
<Raw Results>
[0] sc:503424 lt:0 rt:0 fl:0
[1] sc:503208 lt:0 rt:0 fl:0
[2] sc:50343 lt:0 rt:0 fl:0
[3] sc:50342 lt:0 rt:0 fl:0
[4] sc:50342 lt:0 rt:0 fl:0
in 3600 sec.

<Raw Results2(sum ver.)>
[0] sc:503431 lt:0 rt:0 fl:0
[1] sc:503427 lt:0 rt:0 fl:0
[2] sc:50343 lt:0 rt:0 fl:0
[3] sc:50342 lt:0 rt:0 fl:0
[4] sc:50344 lt:0 rt:0 fl:0

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.47% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

<TpmC>
8390.400 TpmC
=================================================

# ./tpcc_start -h 172.30.2.234 -P 3306 -d tpcc -u root -p coingame -w 50 -c 50 -r 180 -l 3600 -f ./aurora_tpcc_50.log

=================================================
<Raw Results>
[0] sc:673014 lt:0 rt:0 fl:0
[1] sc:672842 lt:0 rt:0 fl:0
[2] sc:67302 lt:0 rt:0 fl:0
[3] sc:67302 lt:0 rt:0 fl:0
[4] sc:67303 lt:0 rt:0 fl:0
in 3600 sec.

<Raw Results2(sum ver.)>
[0] sc:673032 lt:0 rt:0 fl:0
[1] sc:673029 lt:0 rt:0 fl:0
[2] sc:67303 lt:0 rt:0 fl:0
[3] sc:67303 lt:0 rt:0 fl:0
[4] sc:67304 lt:0 rt:0 fl:0

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.47% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

<TpmC>
11216.900 TpmC
=================================================

# ./tpcc_start -h 172.30.2.234 -P 3306 -d tpcc -u root -p coingame -w 50 -c 75 -r 180 -l 3600 -f ./aurora_tpcc_75.log

=================================================
<Raw Results>
[0] sc:868899 lt:0 rt:0 fl:0
[1] sc:868770 lt:0 rt:0 fl:0
[2] sc:86890 lt:0 rt:0 fl:0
[3] sc:86884 lt:0 rt:0 fl:0
[4] sc:86893 lt:0 rt:0 fl:0
in 3600 sec.

<Raw Results2(sum ver.)>
[0] sc:868917 lt:0 rt:0 fl:0
[1] sc:868916 lt:0 rt:0 fl:0
[2] sc:86892 lt:0 rt:0 fl:0
[3] sc:86893 lt:0 rt:0 fl:0
[4] sc:86893 lt:0 rt:0 fl:0

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.47% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

<TpmC>
14481.650 TpmC
=================================================

# ./tpcc_start -h 172.30.2.234 -P 3306 -d tpcc -u root -p coingame -w 50 -c 100 -r 180 -l 3600 -f ./aurora_tpcc_100.log

=================================================
<Raw Results>
[0] sc:849327 lt:0 rt:0 fl:0
[1] sc:849158 lt:0 rt:0 fl:0
[2] sc:84932 lt:0 rt:0 fl:0
[3] sc:84932 lt:0 rt:0 fl:0
[4] sc:84932 lt:0 rt:0 fl:0
in 3600 sec.

<Raw Results2(sum ver.)>
[0] sc:849331 lt:0 rt:0 fl:0
[1] sc:849340 lt:0 rt:0 fl:0
[2] sc:84932 lt:0 rt:0 fl:0
[3] sc:84935 lt:0 rt:0 fl:0
[4] sc:84932 lt:0 rt:0 fl:0

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.47% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

<TpmC>
14155.450 TpmC
=================================================

# ./tpcc_start -h 172.30.2.234 -P 3306 -d tpcc -u root -p coingame -w 50 -c 200 -r 180 -l 3600 -f ./aurora_tpcc_200.log

=================================================
<Raw Results>
[0] sc:895941 lt:0 rt:0 fl:0
[1] sc:895836 lt:0 rt:0 fl:0
[2] sc:89595 lt:0 rt:0 fl:0
[3] sc:89594 lt:0 rt:0 fl:0
[4] sc:89588 lt:0 rt:0 fl:0
in 3600 sec.

<Raw Results2(sum ver.)>
[0] sc:895942 lt:0 rt:0 fl:0
[1] sc:895982 lt:0 rt:0 fl:0
[2] sc:89596 lt:0 rt:0 fl:0
[3] sc:89600 lt:0 rt:0 fl:0
[4] sc:89590 lt:0 rt:0 fl:0

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.48% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

<TpmC>
14932.350 TpmC
=================================================

----

おわり

ベンチマークシリーズ Aurora vs MySQL

2015-08-12T10:07:00.000+09:00

* AmazonAuroraをベンチマークしてみる

** やりたいこと

以下ベンチマークで比較する
・RDS MySQL5.6
・RDS Aurora

** つかうもの

- メリケンのEC2
N.Virginiaのやつ
- tpcc-mysql
ベンチマークツール
以前MySQLとMariaDBを比較した際に、mysqlbenchはフェアではない！と或る方から叱られたため、より実践的なテストを実施する目論見
- bzr
上のやつを取ってくるのに使うPythonのバージョン管理ツール

** まずはtpcc-mysqlを入れる
- yumで入れる

$ sudo su -
# yum install bzr

- 作業ディレクトリの作成と下準備

# mkdir ~/bazaar
# bzr init
# ls -la
■.bzrディレクトリが作成されていることを確認

- tpccmysqlを引っ張ってくる

# bzr branch lp:~percona-dev/perconatools/tpcc-mysql
■失敗します
→AmazonLinuxのpyton2.7とbzrのバージョンがマッチしておらず、initは成功するがそれ以外の動作がおかしい

- bzrを削除して仕切り直し

# yum remove bzr

- bazaar公式から最新の2.6.0のソースを持ってくる

# cd ~
# wget https://launchpad.net/bzr/2.6/2.6.0/+download/bzr-2.6.0.tar.gz

- 解凍とインストール

# tar zxf bzr-2.6.0.tar.gz
# cd bzr-2.6.0
# python setup.py install
■問題なく完了

- 初期設定仕切り直し

# cd ~/bazaar
# bzr init

- ひっぱってくる

# bzr branch lp:~percona-dev/perconatools/tpcc-mysql
■さすが最新エラー無しで完了

** tpcc、tpccをつかう
- tpccを使うためのDBの下準備
-- 試験用のDBをつくる

# mysql -uroot -p
mysql> create database tpcc;
mysql> exit

-- テスト準備用のSQLを流し込む

# cd tpcc-mysql
# mysql -uroot -p tpcc < create_table.sql
# mysql -uroot -p tpcc < add_fkey_idx.sql

- tpcc-mysql側の準備

# cd src
■READMEがscrになっているのはご愛嬌

# make
================================================================================
cc -w -O2 -g -I. `mysql_config --include` -c load.c
cc -w -O2 -g -I. `mysql_config --include` -c support.c
cc load.o support.o `mysql_config --libs_r` -lrt -o ../tpcc_load
cc -w -O2 -g -I. `mysql_config --include` -c main.c
cc -w -O2 -g -I. `mysql_config --include` -c spt_proc.c
cc -w -O2 -g -I. `mysql_config --include` -c driver.c
cc -w -O2 -g -I. `mysql_config --include` -c sequence.c
cc -w -O2 -g -I. `mysql_config --include` -c rthist.c
cc -w -O2 -g -I. `mysql_config --include` -c neword.c
cc -w -O2 -g -I. `mysql_config --include` -c payment.c
cc -w -O2 -g -I. `mysql_config --include` -c ordstat.c
cc -w -O2 -g -I. `mysql_config --include` -c delivery.c
cc -w -O2 -g -I. `mysql_config --include` -c slev.c
cc main.o spt_proc.o driver.o support.o sequence.o rthist.o neword.o payment.o ordstat.o delivery.o slev.o `mysql_config --libs_r` -lrt -o ../tpcc_start
================================================================================

- かくにん

# cd ..
# ls -l
================================================================================
-rw-rw-r-- 1 root root 1506 8月 11 11:22 add_fkey_idx.sql
-rw-rw-r-- 1 root root 317 8月 11 11:22 count.sql
-rw-rw-r-- 1 root root 3485 8月 11 11:22 create_table.sql
-rw-rw-r-- 1 root root 763 8月 11 11:22 drop_cons.sql
drwxrwxr-x 2 root root 4096 8月 11 11:24 src
-rwxrwxr-x 1 root root 47381 8月 11 11:24 tpcc_load ←これが出来上がる
-rwxrwxr-x 1 root root 137049 8月 11 11:24 tpcc_start ←これが出来上がる
================================================================================

- tpcc_load の実行

# ./tpcc_load 127.0.0.1:3306 tpcc root "" 50
■ 書式
$ ./tpcc_load [DBのIPorHostname]:[port] [DBname] [Username] [Password] [WAREHOUSE]
■ WAREHOUSEとはなんぞや？
そのままwarehouse表のレコード数になるとのこと
負荷をかけたいところや目的に応じて数字を変更するようです※要調査

- DBのバックアップを取る

# mysqldump -uroot -p tpcc | gzip > tpcc.sql.gz
■テスト中にDBに変更を加わるため、まっさらな状態でテストするにはいちいちtpcc_loadで
　時間を取られるので、バックアップを取ると吉

- ようやっと試験実施

# ./tpcc_start -h 127.0.0.1 -P 3306 -d tpcc -u root -p "" -w 50 -c 5 -r 180 -l 1800 -f ./tpcc_`date +%Y%m%d%H%M`.log
■ 書式
$ ./tpcc_start -h server_host -P port -d database_name -u mysql_user -p mysql_password -w warehouses -c connections -r warmup_time -l running_time -i report_interval -f report_file
→同時コネクション数はそのままの意味
→warmupは助走時間の設定(大体300秒程度あればいいようです
→running_timeそのままの意味(大体2時間～4時間で測定値にブレがなくなる模樣

- 結果を見る

===========================================================
<Raw Results>
[0] sc:86074 lt:0 rt:0 fl:0
[1] sc:86060 lt:0 rt:0 fl:0
[2] sc:8607 lt:0 rt:0 fl:0
[3] sc:8607 lt:0 rt:0 fl:0
[4] sc:8607 lt:0 rt:0 fl:0
in 1800 sec.

<Raw Results2(sum ver.)>
[0] sc:86074 lt:0 rt:0 fl:0
[1] sc:86071 lt:0 rt:0 fl:0
[2] sc:8607 lt:0 rt:0 fl:0
[3] sc:8607 lt:0 rt:0 fl:0
[4] sc:8607 lt:0 rt:0 fl:0

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.47% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 100.00% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

<TpmC>
2869.133 TpmC (一分間に処理したトランザクション数)
===========================================================

** ここでやっとベンチマーク用のRDSの準備
- スペック

db.r3.xlarge(4core 30GB)で合わせる
→あるていど強くサービスで使いそうなスペックだから

- コンソールでMySQLとAuroraのインスタンスを作成

■Auroraに合わせ新規で北米にRDSを構築したため、セキュリティグループの設定を忘れて接続出来ずに小一時間ハマったのは内緒

- セキュリティグループを設定してEC2からアクセス出来るように！

- データ準備

# host nyowa-cluster.cluster-cr3an1vu6snd.us-east-1.rds.amazonaws.com
nyowa-cluster.cluster-cr3an1vu6snd.us-east-1.rds.amazonaws.com is an alias for nyowa.cr3an1vu6snd.us-east-1.rds.amazonaws.com.
nyowa.cr3an1vu6snd.us-east-1.rds.amazonaws.com has address 172.30.20.128
# host mikunyan-cluster.cluster-cr3an1vu6snd.us-east-1.rds.amazonaws.com
mikunyan-cluster.cluster-cr3an1vu6snd.us-east-1.rds.amazonaws.com is an alias for mikunyan.cr3an1vu6snd.us-east-1.rds.amazonaws.com.
mikunyan.cr3an1vu6snd.us-east-1.rds.amazonaws.com has address 172.30.20.198
■tpcc-mysqlにhostnameが長すぎると怒られるため、IPを確認(IPは適当)

- データの投入開始
-- Aurora

# ./tpcc_load 172.30.20.128 tpcc root PASSWORD 50

-- MySQL

# ./tpcc_load 172.30.20.198 tpcc root PASSWORD 50
■Auroraのデータ作成の遅さに嫌な予感がする
■結局MySQLの二倍くらい時間がかかった・・・

- バックアップ取得
-- Aurora

# mysqldump -uroot -p -h 172.30.2.128 tpcc | gzip > tpcc_aurora.sql.gz
■ディスク容量に注意

-- MySQL

# mysqldump -uroot -p -h 172.30.20.198 tpcc | gzip > tpcc_mysql.sql.gz
■ディスク容量に注意

** いよいよテスト
- テスト
-- Aurora

# ./tpcc_start -h 172.30.20.128 -P 3306 -d tpcc -u root -p [password] -w 50 -c 20 -r 180 -l 3600 -f ./aurora_tpcc.log

-- MySQL

# ./tpcc_start -h 172.30.20.198 -P 3306 -d tpcc -u root -p [password] -w 50 -c 20 -r 180 -l 3600 -f ./mysql_tpcc.log
■connectionの数値を変えつつ 20→30→50→75→100 くらいでパフォーマンスを確認していく

という感じで進めています
結果は来週のこの時間

----

おわり

備忘録：gitをプロキシ環境下で使う方法

2015-06-24T17:55:00.000+09:00

久しぶりなのに、お手軽更新で恐縮です

- なにがしたいの？
NATサーバがないPrivateVPCのEC2みたいな環境からgit cloneしたい。とかいうやつ

- 環境

Server1：squidなんかで立てているproxyサーバ(100.100.100.1:3128)
Server2：PrivateVPCにある箱入りサーバ(192.168.1.1)

- 手順
-- HTTPS通信のプロキシ登録

$ git config --global https.proxy http://100.100.100.1:3128

-- 行頭のgitをhttpsに読み替える的なやつ

$ git config --global url."https://".insteadOf git://

-- 満を持してclone

$ git clone git://github.com/hogehoge/fugafga.git

----

おしまい

ansible で playbook を使ってみる

2015-04-22T20:05:00.001+09:00

ansibleを使ってみた

NTPパッケージをアップデートしてみる

以下の構成で検証
管理サーバ：sigure
対象サーバ：yuzuki

前提条件

今回ansibleユーザーで通信し、rootにsudoを行って、update作業を行うます。
上記から分かる通り、
・ansibleユーザでのログイン
・ansible→rootへのsudo
の権限が必要となります。
事前に、SSHのノンパスログインと、sudoコマンドもNOPASSWDを付けておきます。

hostsをつくる

$ cd /etc/ansible
$ cp -pi hosts{,.org}
$ cat << EOF > hosts
[testserver]
yuzuki.fr.taterole.net
EOF

playbookをつくる

$ mkdir playbook
$ cat << EOF > test.yml
- name: ntp update
hosts: testserver
remote_user: ansible
sudo: yes
vars:
pkg: ntp
tasks:
- name: yum clean
shell: yum clean all
- name: before-check
shell: yum list "{{pkg}}"
register: before_check
- debug: msg="{{before_check.stdout_lines}}"
- name: update "{{pkg}}"
yum: name="{{pkg}}" state=latest
- name: Check again
shell: yum list "{{pkg}}"
register: after_check
- debug: msg="{{after_check.stdout_lines}}"

実行してみる

$ pwd

================================================================================
/etc/ansible
================================================================================

$ ansible-playbook -i hosts playbook/test.yml

================================================================================
[WARNING]: The version of gmp you have installed has a known issue regarding
timing vulnerabilities when used with pycrypto. If possible, you should update
it (i.e. yum update gmp).

PLAY [ntp update] *************************************************************
GATHERING FACTS ***************************************************************
ok: [yuzuki.fr.taterole.net]
TASK: [yum clean] *************************************************************
changed: [yuzuki.fr.taterole.net]
TASK: [before-check] **********************************************************
changed: [yuzuki.fr.taterole.net]
TASK: [debug msg="{{before_check.stdout_lines}}"] *****************************
ok: [yuzuki.fr.taterole.net] => {
"msg": "['Loaded plugins: priorities, update-motd, upgrade-helper', 'Installed Packages', 'ntp.x86_64 4.2.6p5-27.23.amzn1 installed']"
}
TASK: [update "{{pkg}}"] ******************************************************
ok: [yuzuki.fr.taterole.net]
TASK: [Check again] ***********************************************************
changed: [yuzuki.fr.taterole.net]
TASK: [debug msg="{{after_check.stdout_lines}}"] ******************************
ok: [yuzuki.fr.taterole.net] => {
"msg": "['Loaded plugins: priorities, update-motd, upgrade-helper', 'Installed Packages', 'ntp.x86_64 4.2.6p5-27.23.amzn1 installed']"
}
PLAY RECAP *****************************************************************
================================================================================
こんな感じで実行される。(例によって冒頭のWARNINGはシカトしてください)

----
おわり

ansible insall error (ImportError: No module named ansible.runner)

2015-04-22T19:28:00.003+09:00

ansibleを触ってみる

chef使っているけれど、やっぱりpush型のほうが便利かもと思うことがあるので、
ansibleを検証してみるテスト。
が、インストールはしたものの以下のエラーが出たので、困ったというお話。
結構ありがちでは？と思うので共有。

こんなエラー

# ansible --help

============================================================
Traceback (most recent call last):
File "/usr/bin/ansible", line 36, in <module>
from ansible.runner import Runner
ImportError: No module named ansible.runner
============================================================

インストールしたときの記憶

# yum install --enablerepo=epel ansible

====================================================================================================
Package Arch Version Repository Size
====================================================================================================
Installing:
ansible noarch 1.9.0.1-2.el6 epel 1.7 M
Installing for dependencies:
python-crypto2.6 x86_64 2.6.1-2.el6 epel 513 k
python-keyczar noarch 0.71c-1.el6 epel 219 k
python26 x86_64 2.6.9-1.80.amzn1 amzn-updates 5.7 M
python26-PyYAML x86_64 3.10-3.10.amzn1 amzn-main 186 k
python26-babel noarch 0.9.4-5.1.8.amzn1 amzn-main 1.8 M
python26-backports x86_64 1.0-3.14.amzn1 amzn-main 5.2 k
python26-backports-ssl_match_hostname noarch 3.4.0.2-1.12.amzn1 amzn-main 12 k
python26-crypto x86_64 2.6.1-1.10.amzn1 amzn-main 697 k
python26-ecdsa noarch 0.11-3.3.amzn1 amzn-main 77 k
python26-httplib2 noarch 0.7.7-1.5.amzn1 amzn-main 81 k
python26-jinja2 noarch 2.7.2-2.15.amzn1 amzn-main 899 k
python26-libs x86_64 2.6.9-1.80.amzn1 amzn-updates 692 k
python26-markupsafe x86_64 0.11-4.6.amzn1 amzn-main 27 k
python26-paramiko noarch 1.15.1-1.5.amzn1 amzn-main 1.3 M
python26-pyasn1 noarch 0.1.7-2.7.amzn1 amzn-main 174 k
python26-setuptools noarch 12.2-1.30.amzn1 amzn-updates 582 k
python26-simplejson x86_64 3.6.5-1.12.amzn1 amzn-main 210 k
python26-six noarch 1.8.0-1.23.amzn1 amzn-main 31 k
Transaction Summary
====================================================================================================
Install 1 Package (+18 Dependent packages)
Total download size: 15 M
Installed size: 50 M
Is this ok [y/d/N]: y

ansibleはpython2.6でないと稼働しません。が、
AmazonLinuxではデフォルトでpython2.7がインストールされています。

確認

# python --version

Python 2.7.9

こんな感じ。

python26にパッケージ切替

インストール時に2.6が入った事を思い出したので、切替をしていく。

# alternatives --config python

======================================================================
There are 2 programs which provide 'python'.
Selection Command
-----------------------------------------------
*+ 1 /usr/bin/python2.7 ←"+"が付いているのが今使っているバージョン
2 /usr/bin/python2.6
Enter to keep the current selection[+], or type selection number: 2
======================================================================
2番を使いたいので、2を入力してENTERで抜ける。

# python --version

======================================================================
Python 2.6.9
======================================================================
このように表示されれば切替完了。

# ansible 127.0.0.1 -m ping

======================================================================
[WARNING]: The version of gmp you have installed has a known issue regarding
timing vulnerabilities when used with pycrypto. If possible, you should update
it (i.e. yum update gmp).
127.0.0.1 | success >> {
"changed": false,
"ping": "pong"
}
======================================================================
というように表示されればOK

エラー解消

以下のエラーに関してはgmpパッケージのバージョンが古いですよ。という警告

現在AWSリポジトリの最新バージョンでも出てしまいます。

特に影響はないので、放置でも問題ありません。

======================================================================
[WARNING]: The version of gmp you have installed has a known issue regardingtiming vulnerabilities when used with pycrypto. If possible, you should updateit (i.e. yum update gmp).======================================================================

----

おわり

c3.2xlarge vs c4.2xlarge

2015-01-22T20:54:00.002+09:00

AWSで新世代インスタンスが発表されたたので試してみる

* 前置き
-- スペックなんかの違い
Instance vCPU ECU メモリ（GiB）インスタンスストレージ（GB） Linux/UNIX 料金
c3.2xlarge 8 28 15 2 x 80 SSD $0.511 /1 時間
c4.2xlarge 8 31 15 EBS のみ $0.588 /1 時間

このインスタンスを比較対象にしたのは、サービスでc3.2xlargeを使っているからです(安易)
ということで、テストインスタンスでベンチマークを取ってみます。
以下の3点がc3→c4に変わった際の売りになっているそうです
・CPUの世代がHaswellになってクロック数も上がりましたよ。
・ネットワークが最適化されて早くなりましたよ
・ディスク領域がEBSに最適化されて早くなりましたよ

-- お値段
気になるのは料金が結構上がっていることでして、たった$0.77と思うなかれ
安定運用していて1ヶ月単価になると結構な差がでてきます。
・c3.2xlarge：$367.92
・c4.2xlarge：$423.36
$55.44の差額です。たかい。

* ベンチ開始
-- ApacheBench
総アクセス100万
同時connection数がどこまでエラーなくレスポンスを返せるか。

5回同じ項目テストして、エラーが出なかったらOk扱いということで・・・
# ab -n 1000000 -c $cnt http://<hostname>/
→Apacheデフォルトの静的コンテンツ(5.4kb)

- c3.2xlarge
・同時接続370で挫ける
・さばいた秒間リクエスト数の最大は7284.85回/sec
・テスト所要時間は130秒前後

- c4.2xlarge
・同じく同時接続370で挫ける
・さばいた秒間リクエスト数の最大は19130.87回/sec
・テスト所要時間は50秒前後

--ApacheBench総評

・c4.2xlargeが圧勝しました。

-- UnixBench
- c4.2xlarge

# ./Run
------------------------------------------------------------------------
Benchmark Run: Thu Jan 22 2015 09:53:19 - 10:21:26
8 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 38182137.1 lps (10.0 s, 7 samples)
Double-Precision Whetstone 4571.3 MWIPS (10.2 s, 7 samples)
Execl Throughput 4164.7 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1131344.2 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 298746.9 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 3547221.1 KBps (30.0 s, 2 samples)
Pipe Throughput 1996255.2 lps (10.0 s, 7 samples)
Pipe-based Context Switching 52031.5 lps (10.0 s, 7 samples)
Process Creation 11620.3 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 9885.9 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 4096.4 lpm (60.0 s, 2 samples)
System Call Overhead 2905706.4 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 38182137.1 3271.8
Double-Precision Whetstone 55.0 4571.3 831.1
Execl Throughput 43.0 4164.7 968.5
File Copy 1024 bufsize 2000 maxblocks 3960.0 1131344.2 2856.9
File Copy 256 bufsize 500 maxblocks 1655.0 298746.9 1805.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 3547221.1 6115.9
Pipe Throughput 12440.0 1996255.2 1604.7
Pipe-based Context Switching 4000.0 52031.5 130.1
Process Creation 126.0 11620.3 922.2
Shell Scripts (1 concurrent) 42.4 9885.9 2331.6
Shell Scripts (8 concurrent) 6.0 4096.4 6827.4
System Call Overhead 15000.0 2905706.4 1937.1
========
System Benchmarks Index Score 1676.5
------------------------------------------------------------------------
Benchmark Run: Thu Jan 22 2015 10:21:26 - 10:49:35
8 CPUs in system; running 8 parallel copies of tests
Dhrystone 2 using register variables 176334699.4 lps (10.0 s, 7 samples)
Double-Precision Whetstone 32053.7 MWIPS (10.0 s, 7 samples)
Execl Throughput 23787.5 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1011008.1 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 262963.6 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 3250921.8 KBps (30.0 s, 2 samples)
Pipe Throughput 9439625.3 lps (10.0 s, 7 samples)
Pipe-based Context Switching 1686610.1 lps (10.0 s, 7 samples)
Process Creation 66159.9 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 38267.9 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 5348.4 lpm (60.0 s, 2 samples)
System Call Overhead 9603210.3 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 176334699.4 15110.1
Double-Precision Whetstone 55.0 32053.7 5827.9
Execl Throughput 43.0 23787.5 5532.0
File Copy 1024 bufsize 2000 maxblocks 3960.0 1011008.1 2553.1
File Copy 256 bufsize 500 maxblocks 1655.0 262963.6 1588.9
File Copy 4096 bufsize 8000 maxblocks 5800.0 3250921.8 5605.0
Pipe Throughput 12440.0 9439625.3 7588.1
Pipe-based Context Switching 4000.0 1686610.1 4216.5
Process Creation 126.0 66159.9 5250.8
Shell Scripts (1 concurrent) 42.4 38267.9 9025.4
Shell Scripts (8 concurrent) 6.0 5348.4 8914.0
System Call Overhead 15000.0 9603210.3 6402.1
========
System Benchmarks Index Score 5603.6

- c3.2xlarge

# ./Run
------------------------------------------------------------------------
Benchmark Run: Thu Jan 22 2015 06:29:18 - 06:57:23
8 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 35890021.0 lps (10.0 s, 7 samples)
Double-Precision Whetstone 4399.9 MWIPS (9.9 s, 7 samples)
Execl Throughput 4173.9 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1030714.9 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 277165.0 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 3078109.2 KBps (30.0 s, 2 samples)
Pipe Throughput 1755376.0 lps (10.0 s, 7 samples)
Pipe-based Context Switching 45995.4 lps (10.0 s, 7 samples)
Process Creation 11708.5 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 8682.1 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 3581.8 lpm (60.0 s, 2 samples)
System Call Overhead 2423669.1 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 35890021.0 3075.4
Double-Precision Whetstone 55.0 4399.9 800.0
Execl Throughput 43.0 4173.9 970.7
File Copy 1024 bufsize 2000 maxblocks 3960.0 1030714.9 2602.8
File Copy 256 bufsize 500 maxblocks 1655.0 277165.0 1674.7
File Copy 4096 bufsize 8000 maxblocks 5800.0 3078109.2 5307.1
Pipe Throughput 12440.0 1755376.0 1411.1
Pipe-based Context Switching 4000.0 45995.4 115.0
Process Creation 126.0 11708.5 929.2
Shell Scripts (1 concurrent) 42.4 8682.1 2047.7
Shell Scripts (8 concurrent) 6.0 3581.8 5969.7
System Call Overhead 15000.0 2423669.1 1615.8
========
System Benchmarks Index Score 1530.0
------------------------------------------------------------------------
Benchmark Run: Thu Jan 22 2015 06:57:23 - 07:25:33
8 CPUs in system; running 8 parallel copies of tests
Dhrystone 2 using register variables 160166373.8 lps (10.0 s, 7 samples)
Double-Precision Whetstone 29244.4 MWIPS (9.9 s, 7 samples)
Execl Throughput 23354.0 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 764912.1 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 198669.2 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 2652773.6 KBps (30.0 s, 2 samples)
Pipe Throughput 8402747.0 lps (10.0 s, 7 samples)
Pipe-based Context Switching 1447497.7 lps (10.0 s, 7 samples)
Process Creation 62231.2 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 33078.3 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 4566.4 lpm (60.0 s, 2 samples)
System Call Overhead 9414061.7 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 160166373.8 13724.6
Double-Precision Whetstone 55.0 29244.4 5317.2
Execl Throughput 43.0 23354.0 5431.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 764912.1 1931.6
File Copy 256 bufsize 500 maxblocks 1655.0 198669.2 1200.4
File Copy 4096 bufsize 8000 maxblocks 5800.0 2652773.6 4573.7
Pipe Throughput 12440.0 8402747.0 6754.6
Pipe-based Context Switching 4000.0 1447497.7 3618.7
Process Creation 126.0 62231.2 4939.0
Shell Scripts (1 concurrent) 42.4 33078.3 7801.5
Shell Scripts (8 concurrent) 6.0 4566.4 7610.6
System Call Overhead 15000.0 9414061.7 6276.0
========
System Benchmarks Index Score 4894.7

-- UnixBench総評

・こちらも当然c4.2xlargeが勝利
単体Core性能：c4.2xlarge 1676.5 vs c3.2xlarge 1530.0
Core合算性能：c4.2xlarge 5603.6 vs c3.2xlarge 4894.7

----

おわり

Redis hash vs json string

2015-01-22T13:51:00.003+09:00

redisのデータをhashで突っ込むのとjsonをstringで突っ込むの。
どっちがいいのかを試すページを見つけました。

そこでパフォーマンスの比較はされていたのですが、メモリ使用量の差を取りたいなと。

※参考サイト様
http://symfoware.blog68.fc2.com/blog-entry-1446.html

ということで、ざっと10000件の登録と取得テストしてみた結果

-- Hash軍
# Hash形式の登録

0:00:01.591490
0:00:01.616605
0:00:01.472524
0:00:01.546202
0:00:01.659209

# Hash形のデータ取得

0:00:04.343340
0:00:04.458308
0:00:04.224831
0:00:04.489008
0:00:05.694959

# Hash形式のMemory

used_memory:3985912
used_memory_human:3.80M
used_memory_rss:16728064
used_memory_peak:13656576
used_memory_peak_human:13.02M
used_memory_lua:35840
mem_fragmentation_ratio:4.20
mem_allocator:jemalloc-3.6.0

-- json軍
# json形式の登録

0:00:00.446721
0:00:00.451547
0:00:00.427018
0:00:00.470627
0:00:00.395783

# json形式のデータ取得

0:00:05.247353
0:00:04.890471
0:00:05.397085
0:00:04.802723
0:00:05.896350

# Memory

used_memory:4285168
used_memory_human:4.09M
used_memory_rss:16588800
used_memory_peak:13656576
used_memory_peak_human:13.02M
used_memory_lua:35840
mem_fragmentation_ratio:3.87
mem_allocator:jemalloc-3.6.0

----

結果：

登録 hash × - ○ json
参照 hash ○ - △ json
Mem hash ○ - △ json

登録はjsonが圧勝したが、参照に関してはほぼ僅差かつ、若干Hash優勢と巻き返し。
メモリ使用量はHashの方が少ない。
と項目毎に有利な点が出るという、なかなかの好勝負。

利用用途でどちらを使うか決めていったほうがいいですね。
環境のスペック等で若干傾向が変わっていくと思いますので、自分の環境でお試しあれ。

----

おわり

Opensslの脆弱性とその対応

2015-01-16T11:21:00.005+09:00

アップデート用のパッケージが準備されているので、お気軽にアップデート

** 脆弱性概要

English：
https://www.openssl.org/news/secadv_20150108.txt
日本語：
https://jvn.jp/vu/JVNVU98974537/index.html
更に細かく補足頂いているサイト様：
http://xn--u9j0md1592aqmt715c.net/cve-2015-0206/
まとめると：
1.0.1を利用中の方は、1.0.1kにアップデートしなさい。という事。

** アップデートする
- 既存のopensslのバージョン確認
# yum list installed openssl

Loaded plugins: priorities, update-motd, upgrade-helper
Installed Packages
openssl.x86_64 1:1.0.1i-1.78.amzn1 @amzn-updates

# openssl version

OpenSSL 1.0.1i-fips 6 Aug 2014

■どっちかのコマンドで確認

- アップデート実施
# yum update openssl

====================================================================================================
Package Arch Version Repository Size
====================================================================================================
Updating:
openssl x86_64 1:1.0.1k-1.82.amzn1 amzn-updates 1.6 M
Updating for dependencies:
openssl-devel x86_64 1:1.0.1k-1.82.amzn1 amzn-updates 1.5 M
Transaction Summary
====================================================================================================
Upgrade 1 Package (+1 Dependent package)

■依存パッケージのopenssl-develも諸共1.0.1kが用意されている
■大丈夫そうなので、yを入力してアップデート実施

- 確認
# openssl version

OpenSSL 1.0.1k-fips 8 Jan 2015

# yum list installed openssl openssl-devel

Loaded plugins: priorities, update-motd, upgrade-helper
Installed Packages
openssl.x86_64 1:1.0.1k-1.82.amzn1 @amzn-updates
openssl-devel.x86_64 1:1.0.1k-1.82.amzn1 @amzn-updates

■だいじょうぶそうですね

お　わ　り

Docker on AWS EC2

2014-11-28T20:26:00.004+09:00

AWS EC2 Contneir が発表されたので、Dockerを先に触っておこうというコンセプト

- dockerのインストール
# yum install docker.x86_64 docker-devel.x86_64 docker-pkg-devel.x86_64

Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main/latest | 2.1 kB 00:00
amzn-updates/latest | 2.3 kB 00:00
Resolving Dependencies
--> Running transaction check
---> Package docker.x86_64 0:1.2.0-2.21.amzn1 will be installed
--> Processing Dependency: libcgroup for package: docker-1.2.0-2.21.amzn1.x86_64
---> Package docker-devel.x86_64 0:1.2.0-2.21.amzn1 will be installed
--> Processing Dependency: golang for package: docker-devel-1.2.0-2.21.amzn1.x86_64
---> Package docker-pkg-devel.x86_64 0:1.2.0-2.21.amzn1 will be installed
--> Running transaction check
---> Package golang.x86_64 0:1.3.3-1.7.amzn1 will be installed
--> Processing Dependency: golang-bin for package: golang-1.3.3-1.7.amzn1.x86_64
--> Processing Dependency: bzr for package: golang-1.3.3-1.7.amzn1.x86_64
--> Processing Dependency: mercurial for package: golang-1.3.3-1.7.amzn1.x86_64
--> Processing Dependency: golang-src for package: golang-1.3.3-1.7.amzn1.x86_64
---> Package libcgroup.x86_64 0:0.40.rc1-5.11.amzn1 will be installed
--> Running transaction check
---> Package bzr.x86_64 0:2.1.2-2.9.amzn1 will be installed
---> Package golang-pkg-bin-linux-amd64.x86_64 0:1.3.3-1.7.amzn1 will be installed
--> Processing Dependency: golang-pkg-linux-amd64 = 1.3.3-1.7.amzn1 for package: golang-pkg-bin-linux-amd64-1.3.3-1.7.amzn1.x86_64
---> Package golang-src.noarch 0:1.3.3-1.7.amzn1 will be installed
---> Package mercurial.x86_64 0:2.6.3-1.22.amzn1 will be installed
--> Running transaction check
---> Package golang-pkg-linux-amd64.noarch 0:1.3.3-1.7.amzn1 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
====================================================================================================
Package Arch Version Repository Size
====================================================================================================
Installing:
docker x86_64 1.2.0-2.21.amzn1 amzn-updates 4.9 M
docker-devel x86_64 1.2.0-2.21.amzn1 amzn-updates 259 k
docker-pkg-devel x86_64 1.2.0-2.21.amzn1 amzn-updates 111 k
Installing for dependencies:
bzr x86_64 2.1.2-2.9.amzn1 amzn-main 5.9 M
golang x86_64 1.3.3-1.7.amzn1 amzn-updates 3.0 M
golang-pkg-bin-linux-amd64 x86_64 1.3.3-1.7.amzn1 amzn-updates 15 M
golang-pkg-linux-amd64 noarch 1.3.3-1.7.amzn1 amzn-updates 8.7 M
golang-src noarch 1.3.3-1.7.amzn1 amzn-updates 6.4 M
libcgroup x86_64 0.40.rc1-5.11.amzn1 amzn-main 146 k
mercurial x86_64 2.6.3-1.22.amzn1 amzn-main 3.7 M
Transaction Summary
====================================================================================================
Install 3 Packages (+7 Dependent packages)
Total download size: 48 M
Installed size: 176 M
Is this ok [y/d/N]: y
Downloading packages:
(1/10): bzr-2.1.2-2.9.amzn1.x86_64.rpm | 5.9 MB 00:00
(2/10): docker-1.2.0-2.21.amzn1.x86_64.rpm | 4.9 MB 00:00
(3/10): docker-devel-1.2.0-2.21.amzn1.x86_64.rpm | 259 kB 00:00
(4/10): docker-pkg-devel-1.2.0-2.21.amzn1.x86_64.rpm | 111 kB 00:00
(5/10): golang-1.3.3-1.7.amzn1.x86_64.rpm | 3.0 MB 00:00
(6/10): golang-pkg-bin-linux-amd64-1.3.3-1.7.amzn1.x86_64.rpm | 15 MB 00:00
(7/10): golang-pkg-linux-amd64-1.3.3-1.7.amzn1.noarch.rpm | 8.7 MB 00:00
(8/10): golang-src-1.3.3-1.7.amzn1.noarch.rpm | 6.4 MB 00:00
(9/10): libcgroup-0.40.rc1-5.11.amzn1.x86_64.rpm | 146 kB 00:00
(10/10): mercurial-2.6.3-1.22.amzn1.x86_64.rpm | 3.7 MB 00:00
----------------------------------------------------------------------------------------------------
Total 42 MB/s | 48 MB 00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : bzr-2.1.2-2.9.amzn1.x86_64 1/10
Installing : libcgroup-0.40.rc1-5.11.amzn1.x86_64 2/10
Installing : mercurial-2.6.3-1.22.amzn1.x86_64 3/10
Installing : golang-src-1.3.3-1.7.amzn1.noarch 4/10
Installing : golang-pkg-linux-amd64-1.3.3-1.7.amzn1.noarch 5/10
Installing : golang-1.3.3-1.7.amzn1.x86_64 6/10
Installing : golang-pkg-bin-linux-amd64-1.3.3-1.7.amzn1.x86_64 7/10
Installing : docker-pkg-devel-1.2.0-2.21.amzn1.x86_64 8/10
Installing : docker-devel-1.2.0-2.21.amzn1.x86_64 9/10
Installing : docker-1.2.0-2.21.amzn1.x86_64 10/10
Verifying : golang-1.3.3-1.7.amzn1.x86_64 1/10
Verifying : golang-src-1.3.3-1.7.amzn1.noarch 2/10
Verifying : docker-1.2.0-2.21.amzn1.x86_64 3/10
Verifying : mercurial-2.6.3-1.22.amzn1.x86_64 4/10
Verifying : golang-pkg-bin-linux-amd64-1.3.3-1.7.amzn1.x86_64 5/10
Verifying : docker-pkg-devel-1.2.0-2.21.amzn1.x86_64 6/10
Verifying : docker-devel-1.2.0-2.21.amzn1.x86_64 7/10
Verifying : libcgroup-0.40.rc1-5.11.amzn1.x86_64 8/10
Verifying : golang-pkg-linux-amd64-1.3.3-1.7.amzn1.noarch 9/10
Verifying : bzr-2.1.2-2.9.amzn1.x86_64 10/10
Installed:
docker.x86_64 0:1.2.0-2.21.amzn1 docker-devel.x86_64 0:1.2.0-2.21.amzn1
docker-pkg-devel.x86_64 0:1.2.0-2.21.amzn1
Dependency Installed:
bzr.x86_64 0:2.1.2-2.9.amzn1
golang.x86_64 0:1.3.3-1.7.amzn1
golang-pkg-bin-linux-amd64.x86_64 0:1.3.3-1.7.amzn1
golang-pkg-linux-amd64.noarch 0:1.3.3-1.7.amzn1
golang-src.noarch 0:1.3.3-1.7.amzn1
libcgroup.x86_64 0:0.40.rc1-5.11.amzn1
mercurial.x86_64 0:2.6.3-1.22.amzn1
Complete!

■すんなり

- Dockerのインストール確認
# docker version

Client version: 1.2.0
Client API version: 1.14
Go version (client): go1.3.3
Git commit (client): fa7b24f/1.2.0
OS/Arch (client): linux/amd64
2014/11/17 10:10:53 Get http:///var/run/docker.sock/v1.14/version: dial unix /var/run/docker.sock: no such file or directory

■インストールされたバージョンをながめる

# docker info

Containers: 0
Images: 0
Storage Driver: devicemapper
Pool Name: docker-202:1-269202-pool
Pool Blocksize: 64 Kb
Data file: /var/lib/docker/devicemapper/devicemapper/data
Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
Data Space Used: 293.0 Mb
Data Space Total: 102400.0 Mb
Metadata Space Used: 0.7 Mb
Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.14.20-20.44.amzn1.x86_64
Operating System: Amazon Linux AMI 2014.09

■Dockerの情報が表示される。コンテナも作ってないしイメージもないので、0ですね。

- Dockerを使いはじめる
# /etc/init.d/docker start
■プロセスのスタート

-- 必要であれば以下も
# chkconfig docker on
■これでインスタンスリブート時に勝手にDockerが上がる

- AmazonLinuxのイメージをさがす

https://registry.hub.docker.com/
ここで必要なパッケージをさがしませう。
今回はAWSなので、Docker上もAmazonLinuxを使う方向で。
→どうやらLatestがまだ2014.03の模様

- OSイメージの取得
# docker pull vettl/amazon-linux:latest

Pulling repository vettl/amazon-linux
0a270722a07c: Download complete
d25f22b5d1eb: Download complete

- ダウンロードしたイメージの確認
# docker images

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
vettl/amazon-linux latest 0a270722a07c 7 months ago 607.8 MB

- コンテナ作成コマンドの確認
# docker run

Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
Run a command in a new container
-a, --attach=[] Attach to STDIN, STDOUT or STDERR.
-c, --cpu-shares=0 CPU shares (relative weight)
--cap-add=[] Add Linux capabilities
--cap-drop=[] Drop Linux capabilities
--cidfile="" Write the container ID to the file
--cpuset="" CPUs in which to allow execution (0-3, 0,1)
-d, --detach=false Detached mode: run container in the background and print new container ID
--device=[] Add a host device to the container (e.g. --device=/dev/sdc:/dev/xvdc)
--dns=[] Set custom DNS servers
--dns-search=[] Set custom DNS search domains
-e, --env=[] Set environment variables
--entrypoint="" Overwrite the default ENTRYPOINT of the image
--env-file=[] Read in a line delimited file of environment variables
--expose=[] Expose a port from the container without publishing it to your host
-h, --hostname="" Container host name
-i, --interactive=false Keep STDIN open even if not attached
--link=[] Add link to another container in the form of name:alias
--lxc-conf=[] (lxc exec-driver only) Add custom lxc options --lxc-conf="lxc.cgroup.cpuset.cpus = 0,1"
-m, --memory="" Memory limit (format: <number><optional unit>, where unit = b, k, m or g)
--name="" Assign a name to the container
--net="bridge" Set the Network mode for the container
'bridge': creates a new network stack for the container on the docker bridge
'none': no networking for this container
'container:<name|id>': reuses another container network stack
'host': use the host network stack inside the container. Note: the host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.
-P, --publish-all=false Publish all exposed ports to the host interfaces
-p, --publish=[] Publish a container's port to the host
format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort
(use 'docker port' to see the actual mapping)
--privileged=false Give extended privileges to this container
--restart="" Restart policy to apply when a container exits (no, on-failure, always)
--rm=false Automatically remove the container when it exits (incompatible with -d)
--sig-proxy=true Proxy received signals to the process (even in non-TTY mode). SIGCHLD, SIGSTOP, and SIGKILL are not proxied.
-t, --tty=false Allocate a pseudo-TTY
-u, --user="" Username or UID
-v, --volume=[] Bind mount a volume (e.g., from the host: -v /host:/container, from Docker: -v /container)
--volumes-from=[] Mount volumes from the specified container(s)
-w, --workdir="" Working directory inside the container

- いざ鎌倉
# docker run -it --name AmazonLinux1 vettl/amazon-linux /bin/bash

[root@eaf067a49fc7 /]#
こんなふうにプロンプトが変更され、Dockerの中でRootuserとして生を受ける

==== ポインツ ==================================================================
exitで元のホストに戻ることができるけど、SSH等のサービスを上げていない場合は、ログインできる術がなくなってしまう
HTTPDインスタンスや、DBインスタンス等の場合、SSHのサービス自体を起動させないことで、セキュリティリスクを
減らすことが出来るのもDockerの強みなので、SSHを使わずに、中身を編集する方法がほしい
================================================================================

- 解決方法 nsenter、nsenterをつかう
-- nsenterのインストール
# docker run -v /usr/local/bin:/target jpetazzo/nsenter

nsenterを簡単に使うために、以下のスクリプトを用意する

# vi /usr/local/bin/nsenter_sh

=======================================================================
#!/bin/bash
#
# Contaner login script
if [ -z $1 ] ; then
echo "usage: nsenter_sh [ContainerID]"
exit 1
else
PID=$(docker inspect --format {{.State.Pid}} $1)
nsenter --target $PID --mount --uts --ipc --net --pid
fi
exit 0
=======================================================================

# chmod 755 nsenter_sh

権限変更して簡単起動に

- 動作確認
# nsenter eaf067a49fc7

[root@eaf067a49fc7 /]#
■プロンプトがかわることを確認

おしまい
=====

ということで、Dockerのインストールと簡単ログインのお話でした。

Route53がVPCのPrivateDNSに使えるようになったと聞いて

2014-11-12T10:26:00.001+09:00

Route53でPrivateDNSを使ってみる

自分で内部DNSを構築したり、/etc/hostsの力業を使わない限り、今までは長い名前を頑張って入れるかIPアドレス経由でアクセスをする必要がある。

・内部DNSを利用するにはBINDの脆弱性と戦ったりせざるを得ず、毎年の恒例行事でやってられない。
・RDSやRedshiftやElasticacheを利用している方々なら分かると思うが、Endpointの名前が長すぎるので、CNAMEが使えるととても楽。

ということで、Route53 in VPCを試してみるテスト。

1,Route53の画面を眺めてみる。

いつもの設定と同じく、[Create Hosted Zone] を押す。

2,項目について

見慣れない項目が増えている…。

項目について：
Domain Name:VPC内で使うInternalのドメイン・ネームを入力
Comment :上記ドメインの説明など
Type :PrivateDNSかPublicDNSかを選択
VPC Id :上記でPrivateを選択した際に、どのVPCに適用するかを選択

3,設定してみた

-- Privateを3つ作成してみた

bk.taterole.net：バックエンド用ドメイン
バックエンド用途、VPC内のInternet側に向かわない通信用のドメイン
webサーバ→DBサーバの通信や、Cacheサーバなどを用いる際にこのネットワークを利用する

fr.taterole.net：フロントエンド用ドメイン
フロントエンド用途、InternetGatewayをもったdefaultVPCと通信用のドメイン
ELB→webサーバの通信みたいな用途

gw.taterole.net：ゲートウェイ用ドメイン
追加したPrivateVPCではなく、DefaultVPC用のドメイン
踏み台サーバなどを配置する用途

4,検証用EC2インスタンス
-- DefaultVPCに配置

Hostname：shimakaze
eth0：shimakaze.gw.taterole.net
せつめい：踏み台サーバとして作成

-- PrivateVPCに配置

Hostname：sigure
eth0：kiso.bk.taterole.net
eth1：kiso.fr.taterole.net
せつめい：PrivateVPC上でWEBサーバを想定して構築したもの
RDS/Elasticache通信用のeth0とフロントからの通信を受ける用のeth1を用意

5,Route53にそれぞれのレコードセットに、インスタンスのPrivateDNSを登録

-- gw.taterole.net.
shimakaze.gw.taterole.net. Aレコード 172.16.30.1
-- fr.taterole.net.
kiso.fr.taterole.net. Aレコード 172.16.1.1
-- bk.taterole.net.
kiso.bk.taterole.net. Aレコード 172.16.101.1
※IPはインスタンスを作成時にDHCPで割り当てられたIPです。

6,動作確認

-- PrivateVPCインスタンスから確認(kiso)
[taterole@kiso ~]$ host kiso.bk.taterole.net
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; no servers could be reached
[taterole@kiso ~]$ host kiso.fr.taterole.net
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; no servers could be reached
[taterole@kiso ~]$ host shimakaze.gw.taterole.net
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; no servers could be reached
→アカン

-- DefaultVPCインスタンスから確認(shimakaze)
[taterole@shimakaze ~]$ host shimakaze.gw.taterole.net
shimakaze.gw.taterole.net has address 172.16.30.1
[taterole@shimakaze ~]$ host kiso.fr.taterole.net
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; no servers could be reached
[taterole@shimakaze ~]$ host kiso.bk.taterole.net
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; trying next origin
;; connection timed out; no servers could be reached
→gw.tateroleだけ引ける模様

7,ドキュメントを読み解いてみる…。

ImportantTo use private hosted zones, you must set the following Amazon VPC settings to true:
・enableDnsHostnames
・enableDnsSupport
For more information, see Updating DNS Support for Your VPC in the Amazon VPC User Guide.

なるほど。

8,VPCの設定を変更

以前VPCを作成された方は、デフォルトの[DNS hostnames] が[no]になっています。
ココを[yes]に変更。

9,もっかい動作確認

-- PrivateVPCインスタンスから確認(kiso)
[taterole@kiso ~]$ host shimakaze.gw.taterole.net
shimakaze.gw.taterole.net has address 172.16.30.1
[taterole@kiso ~]$ host kiso.fr.taterole.net
shimakaze.fr.taterole.net has address 172.16.1.1
[taterole@kiso ~]$ host kiso.bk.taterole.net
shimakaze.bk.taterole.net has address 172.16.101.1
→ヤッター！

-- DefaultVPCインスタンスから確認(shimakaze)
[taterole@shimakaze ~]$ host shimakaze.gw.taterole.net
shimakaze.gw.taterole.net has address 172.16.30.1
[taterole@shimakaze ~]$ host kiso.fr.taterole.net
shimakaze.fr.taterole.net has address 172.16.1.1
[taterole@shimakaze ~]$ host kiso.bk.taterole.net
shimakaze.bk.taterole.net has address 172.16.101.1
→タツジン！

10,おまけにRDSも以下でDNS登録して名前が引けることを確認

-- bk.taterole.net.
kongo.bk.taterole.net. CNAME kongo.hogehoge.ap-northeast-1.rds.amazonaws.com.
→EndpointにCNAMEを貼る感じで、アクセス出来やすいようにします。
　IPアドレスはMultiAZなど使っている場合、一意ではないのでCNAME推奨だと思われます

[taterole@kiso ~]$ host kongo
kongo.bk.taterole.net is an alias for kongo.hogehoge.ap-northeast-1.rds.amazonaws.com.
kongo.hogehoge.ap-northeast-1.rds.amazonaws.com has address 172.16.101.225
→うむ、長い名前がすごく短くなった

---

注意点としては、VPCの設定変更を忘れないというところ

---

ということで、おわり。

Apache→Fluentd→Redshift でデータ投入する話

2014-08-27T11:23:00.001+09:00

fluentd→(S3)→Redshiftの構成で、データの集積と一括管理をしたいとおもいました

fluentd側でアクセスログをJson化してS3に配置、そのままRedshiftへコピーという流れを、便利なモジュールが担ってくれる楽ちん構成

やること：
1,)fluentdのインストール
2,)fluentdの各種plugin追加
3,)fluentdのconf作成
4,)fluentdの起動
5,)Redshift側のテーブル作成
6,)データの確認

----------------------------------------------------------------------------

1,)fluentdのインストール
-- リポジトリ追加

# vi /etc/yum.repos.d/td.repo
======================================================================
[treasuredata]
name=TreasureData
baseurl=http://packages.treasure-data.com/redhat/$basearch
gpgcheck=0
======================================================================

-- インストール

# yum install td-agent
======================================================================
Dependencies Resolved
====================================================================================================
Package Arch Version Repository Size
====================================================================================================
Installing:
td-agent x86_64 1.1.20-0 treasuredata 64 M
Installing for dependencies:
compat-libtermcap x86_64 2.0.8-49.2.amzn1 amzn-main 16 k
compat-readline5 x86_64 5.2-17.3.amzn1 amzn-main 156 k
openssl098e x86_64 0.9.8e-18.2.14.amzn1 amzn-updates 892 k
td-libyaml x86_64 0.1.4-1 treasuredata 126 k
Transaction Summary
====================================================================================================
Install 1 Package (+4 Dependent packages)
Total download size: 65 M
Installed size: 112 M
Is this ok [y/d/N]: y
======================================================================

2,)fluentdの各種plugin追加
-- モジュールの追加

# yum install postgresql9.x86_64 postgresql9-devel.x86_64
■前提として、redshift接続用のポスグレクライアントが必要っす

-- プラグインのインストール

# /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-redshift
# /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-jsonbucket
■gemコマンドではなくfluent-gemのコマンドであることに注意っす
■他に必要なpluginが有る場合は、ここでガシガシ追加

3,)fluentdのconf作成

# vi /etc/td-agent/td-agent.conf
■テンプレをちょいちょい変更して作成
====================================================================================================
## Input
<source>
type tail
path /var/log/httpd/shq_gree/access_log.%Y%m%d
format /^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<request_time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<status>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)" (?<response_time>[^ ]*))?$/
time_format %d/%b/%Y:%H:%M:%S %z
pos_file /var/log/td-agent/tmp/apache.access.log.pos
tag apache.access
</source>
<match apache.access>
type jsonbucket
output_tag redshift.apache.access
json_key log
</match>
<match redshift.apache.access>
type redshift
# s3 (for copying data to redshift)
aws_key_id <youe_aws_key_id> #AWSキーをいれる
aws_sec_key <your_aws_sec_key> #シークレットキーを入れる
s3_bucket redshift #S3上のどのバケットにデータを配置するか
s3_endpoint <your_region_name> #リージョン一覧から、利用しているリージョンを入れる
path for_redshift/
timestamp_key_format %Y%m%d/%Y%m%d-%H%M #S3上にどういうパスでデータが配置したいかを指定
# redshift
redshift_host <your_redshift_end_point> #Redshiftの管理コンソールからエンドポイントを確認
redshift_port 5439 #Redshiftが使ってるポートを指定
redshift_dbname <your_db_name> #Redshiftでデータを投入するDB名
redshift_user <rs_user_name> #Redshiftのユーザ
redshift_password <rs_user_pass> #上記ユーザのパス
redshift_schemaname public #変更指定なければ、publicがデフォ
redshift_tablename access_log #データを投入するテーブル名
redshift_copy_base_options TIMEFORMAT 'auto' TRUNCATECOLUMNS COMPUPDATE ON #詳細はこの後
file_type json
# buffer
buffer_type file
buffer_path /var/log/td-agent/buffer/redshift #一時ファイルの置き場
flush_interval 10m #一時ファイルを何分間隔でflushしてS3→Redshiftにデータを送るか
buffer_chunk_limit 1g #一時ファイルのデータリミット指定
</match>
====================================================================================================

※<source>ディレクティブの正規表現について

apacheログと正規表現を見比べつつ、正常にバッファファイルに出力されているかを確認しつつ
ポリシーを作っていく。
ここでのポイントは、データ内にTimestampを残したい場合、<time>の指定だと、fluentdでattribute
扱いになって、BODYにデータが入りません。
データを扱う上で、Timestampが残らないのは具合が悪いので、<request_time>という<time>以外のKey
を指定することで、BODY内にデータが入るようにしています。

下記サイトで正規表現の正否が確認できるので参考にどうぞ
http://fluentular.herokuapp.com/

※redshift_copy_base_optionsについて

Redshiftへデータを投入するCOPYコマンドにつけるオプションをここに書く
(gitのReadmeに書いてなくてすげー探した)
---- TIMEFORMAT 'auto'
Apacheログの場合、Timestampの出力が
[27/Aug/2014:00:00:00 +0900]
という形このまま突っ込んでも、Redshiftが持っているデフォルトの日付フォーマットに準拠していないため、nullが入ってしまう
それを回避するためにいれてるっす。
---- TRUNCATECOLUMNS
CLOMUNにデータを入れる際に文字数をオーバーするときにカットする
---- COMPUPDATE ON
データの圧縮をして容量の削減
CREATE TABLEする時に、データ圧縮を有効にしたうえでつかいませう

詳細はこちら
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_COPY.html

4,)fluentdの起動
-- コンフィグテスト

# /etc/init.d/td-agent configtest

-- スタート

# /etc/init.d/td-agent start

-- 自動起動設定

# chkconfig td-agent on

5,)Redshift側のテーブル作成

# psql -U <user> -W -h <redshift_end_point> -d <db_name> -p <port_num>
<db_name>=# \d access_log■こんなかんじで作るます
■CREATE TABLE で圧縮も使えるように設定しておく
====================================================================================================
Table "public.access_log"
Column | Type | Modifiers
---------------+-----------------------------+-----------------------------------------
host | character varying(15) | not null default '-'::character varying
user | character varying(255) | not null default '-'::character varying
request_time | timestamp without time zone | not null
method | character varying(10) | not null default '-'::character varying
path | character varying(65535) | not null
status | character varying(3) | not null default '-'::character varying
size | character varying(255) | not null default '0'::character varying
referer | character varying(65535) | not null default '-'::character varying
agent | character varying(255) | not null default '-'::character varying
response_time | character varying(255) | not null default '-'::character varying
====================================================================================================

6,)データの確認

# psql -U <user> -W -h <redshift_end_point> -d <db_name> -p <port_num>
<db_name>=# select * from access_log;
host | user | request_time | method | path | status | size | refer
-----------------+-------+----------------------------+--------+----------------------+--------+-------+----------------------------------
111.222.111.222 | - | 27/Aug/2014:19:50:26 +0900 | GET | /index.html | 200 | 2145 | https://kirarin.taterole.co.jp/
■長いので途中できってます

-------------------------
おしまい

RDSでTimezoneを変更するストアドを入れているとMySQL has gone awayされる件

2014-08-19T19:37:00.001+09:00

いろいろなサイトを調べた結果、結構な人が困っている様子。

UTCのママ使って、プログラム側で毎回設定してもいいけれど、今までの別の
システムで動かしていた物を移設となると、なるべく既存の物に手を入れたくないのが人情

サポートに問い合わせつつ、解決の目を見たので、備忘録兼ねて
----------------------------------------------------------------------------

状況を再現させる
0,)ふつうにRDSのインスタンスを作る
どんなスペックでもかまわないです。
TimezoneがUTC固定のため、日本時間-9:00になっている

1,)Timezoneを変更するストアドを作る

-- 格納するデータベースをさくせい
mysql> CREATE DATABASE shared;

-- すとあど
mysql> DELIMITER |
CREATE PROCEDURE shared.`store_time_zone`()
IF NOT (POSITION('rdsadmin@' IN CURRENT_USER()) = 1) THEN
SET SESSION time_zone = 'Asia/Tokyo';
END IF |
Query OK, 0 rows affected (0.01 sec)

-- 適用
mysql> DELIMITER ;

-- 確認
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2014-08-19 08:25:59 |
+---------------------+
1 row in set (0.02 sec)

-- 読んでみる
mysql> CALL shared.store_time_zone;
Query OK, 0 rows affected (0.10 sec)

-- 日本時間で表示されていることを確認
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2014-08-19 17:26:08 |
+---------------------+
1 row in set (0.02 sec)

-- 参考サイト様
http://dev.classmethod.jp/cloud/aws/change-timezone-on-amazon-rds-mysql/

2,)ユーザーを作ってみる

GRANT ALL PRIVILEGES ON `%`.* TO 'testuser'@'%' IDENTIFIED BY 'testuser' WITH GRANT OPTION;

3,)再現チェック

$ mysql -utestuser -p -h <RDS_Endpoint>
mysql> show databases;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 1195762
Current database: *** NONE ***
ERROR 1184 (08S01): Aborted connection 1195762 to db: 'unconnected' user: 'testuser' host: '111.222.111.222' (init_connect command failed)

4,)EXECUTE権限をユーザに付与

RDS構築時の管理ユーザでmysqlへログイン
mysql> grant execute on *.* to 'testuser'@'%';

5,)変更かくにん

mysql> SELECT * FROM mysql.user\G
====================
Execute_priv: Y
====================

6,)動作確認

$ mysql -utestuser -p -h <RDS_Endpoint>
mysql> show databases;
+------------------------+
| Database |
+------------------------+
| information_schema |
| innodb |
| testdb |
| mysql |
| performance_schema |
| shared |
| tmp |
+------------------------+
19 rows in set (0.00 sec)

-----------------
なおった！

BIND10スタートアップガイド(震え声) vol.1

2013-02-25T12:35:00.001+09:00

BIND10のrc版が出たと聞いて飛んできました

** 目的
BIND10であそんでみよう。
色々モジュール化されたりで、かなり変わっているとのお話ですし。

** 環境
Cent6.3(さくらVPS1480円プラン)

** 参考にしたもの
http://bind10.isc.org/docs/bind10-guide.html#quick-start-auth-dns

** インストールをはじめるよ
-- 任意の場所にもってくる

# cd /usr/local/src
# wget ftp://ftp.isc.org/isc/bind10/1.0.0-rc/bind10-1.0.0-rc.tar.gz

-- かいとう

# tar zxf bind10-1.0.0-rc.tar.gz

-- こんぱいる

# cd bind10-1.0.0-rc
# ./configure --prefix /usr/local/bind10
----------------------------------------------------------------------
configure: error: no suitable Python interpreter found
----------------------------------------------------------------------

お？えらーが。
ドキュメントを読んでみたところ、python3.1以降が入っていないとだめらしい。

-- pythonバージョン確認

# yum list installed python
----------------------------------------------------------------------
python.x86_64 2.6.6-29.el6_3.3
----------------------------------------------------------------------

まったく太刀打ちできない。

** pythonをあたらしくする
remi remi-test とかみても、3.1以上のpythonがなかったので、ソースから。

-- ソースを持ってくる

# cd /usr/local/src
# wget http://www.python.org/ftp/python/3.3.0/Python-3.3.0.tgz

-- かいとう

# tar zxf Python-3.3.0.tgz

-- のーみそこねこね

# ./configure --prefix=/usr/local/python
# make
# make test
----------------------------------------------------------------------
FAIL: test_urlwithfrag (test.test_urllib2net.OtherNetworkTests)
----------------------------------------------------------------------

テストえらーでましたね。
でもこの機能はBIND10のインストールに必要ない（思いこみ
ということで次へ。

# make install

何事もなくインストール完了（棒

** BIND10にリベンジ
-- みたびこんぱいる

# cd /usr/local/src/bind10-1.0.0-rc
# ./configure --with-pythonpath=/usr/local/python/bin/python3 --prefix=/usr/local/bind10

ソースでpythonをぶっこんだので、"--with-pythonpath" で指定してやります。
さらにbotan・log4cplusが必要とわかったので、インストールしておく。

--- botan

# yum install botan.x86_64 botan-devel.x86_64

--- log4cplus

# cd /usr/local/src
# wget http://downloads.sourceforge.net/project/log4cplus/log4cplus-stable/1.0.4/log4cplus-1.0.4.tar.bz2
# tar jxf log4cplus-1.0.4.tar.bz2
# cd log4cplus-1.0.4
# ./configure --prefix=/opt/log4cplus
# make
# make install

-- よたびこんぱいる

# make distclean
# autoreconf --install
# ./configure --prefix=/usr/local/bind10 \
--with-pythonpath=/usr/local/python/bin/python3 \
--with-log4cplus=/usr/local/log4cplus
# make
# make test
# make install

なんとかインストール完了。。

** 起動してみる
-- ユーザーさくせい

# cd /usr/local/bind10/etc/bind10
# /usr/local/bind10/sbin/b10-cmdctl-usermgr
----------------------------------------------------------------------
Desired Login Name:lapo <- ユーザー名を入力
Choose a password: <- パスワードを入力
Re-enter password: <- パスワードを入力
create new account successfully!
continue to create new account by input 'y' or 'Y': <- さらにユーザー追加する場合はy or Y しない場合はそのまま<Enter>
----------------------------------------------------------------------

-- 起動

# /usr/local/bind10/sbin/bind10
----------------------------------------------------------------------
FATAL [b10-cmdctl.cmdctl]: CMDCTL_UNCAUGHT_EXCEPTION uncaught exception: Error creating server, because: [Errno 98] Address already in use
----------------------------------------------------------------------
■こんなエラーが出てあがらにゃい

→どうやらbindctlで8080ポートを使うみたい。Nginx→apacheの部分で8080を使っていたので競合したぽい。
Nginx側を10080に変更して難を逃れることに。

-- もっかい起動

# /usr/local/bind10/sbin/bind10
----------------------------------------------------------------------
YYYY-MM-DD HH:MM:SS.123 INFO [b10-cfgmgr.cfgmgr/4750] CFGMGR_CONFIG_FILE Configuration manager starting with configuration file: /usr/local/bind10/var/bind10/b10-config.db
YYYY-MM-DD HH:MM:SS.996 INFO [b10-init.init/4746] BIND10_STARTING starting BIND10: bind10 20110223 (BIND 10 1.0.0-rc)
YYYY-MM-DD HH:MM:SS.996 INFO [b10-init.init/4746] BIND10_CONFIGURATOR_START bind10 component configurator is starting up
YYYY-MM-DD HH:MM:SS.996 INFO [b10-init.init/4746] BIND10_COMPONENT_START component Socket creator is starting
YYYY-MM-DD HH:MM:SS.996 INFO [b10-init.init/4746] BIND10_SOCKCREATOR_INIT initializing socket creator parser
YYYY-MM-DD HH:MM:SS.996 INFO [b10-init.init/4746] BIND10_COMPONENT_START component msgq is starting
YYYY-MM-DD HH:MM:SS.996 INFO [b10-init.init/4746] BIND10_STARTING_PROCESS starting process b10-msgq
YYYY-MM-DD HH:MM:SS.996 INFO [b10-init.init/4746] BIND10_COMPONENT_START component cfgmgr is starting
YYYY-MM-DD HH:MM:SS.996 INFO [b10-init.init/4746] BIND10_STARTING_PROCESS starting process b10-cfgmgr
YYYY-MM-DD HH:MM:SS.996 INFO [b10-init.init/4746] BIND10_STARTING_CC starting configuration/command session
YYYY-MM-DD HH:MM:SS.009 INFO [b10-init.init/4746] BIND10_READING_INIT_CONFIGURATION reading b10-init configuration
YYYY-MM-DD HH:MM:SS.010 INFO [b10-init.init/4746] BIND10_CONFIGURATOR_RECONFIGURE reconfiguring running components
YYYY-MM-DD HH:MM:SS.011 INFO [b10-init.init/4746] BIND10_COMPONENT_START component b10-cmdctl is starting
YYYY-MM-DD HH:MM:SS.011 INFO [b10-init.init/4746] BIND10_STARTING_PROCESS starting process b10-cmdctl
YYYY-MM-DD HH:MM:SS.019 INFO [b10-init.init/4746] BIND10_COMPONENT_START component b10-stats is starting
YYYY-MM-DD HH:MM:SS.019 INFO [b10-init.init/4746] BIND10_STARTING_PROCESS starting process b10-stats
YYYY-MM-DD HH:MM:SS.031 INFO [b10-init.init/4746] BIND10_STARTUP_COMPLETE BIND 10 started
YYYY-MM-DD HH:MM:SS.203 INFO [b10-stats.stats/4753] STATS_STARTING starting
----------------------------------------------------------------------
■無事起動

大丈夫だったのでまつびぃに"&"をつけてバックグラウンドで。

-- 起動と確認

# /usr/local/bind10/sbin/bind10 &
# ps -ef | grep b10
----------------------------------------------------------------------
root 4755 4631 0 11:28 pts/0 00:00:00 /usr/local/python/bin/python3 /usr/local/bind10/libexec/bind10/b10-init
root 4756 4755 0 11:28 pts/0 00:00:00 b10-sockcreator
root 4757 4755 0 11:28 pts/0 00:00:00 /usr/local/python/bin/python3 /usr/local/bind10/libexec/bind10/b10-msgq
root 4759 4755 0 11:28 pts/0 00:00:00 /usr/local/python/bin/python3 /usr/local/bind10/libexec/bind10/b10-cfgmgr
root 4761 4755 0 11:28 pts/0 00:00:00 /usr/local/python/bin/python3 /usr/local/bind10/libexec/bind10/b10-stats
root 4762 4755 0 11:28 pts/0 00:00:00 /usr/local/python/bin/python3 /usr/local/bind10/libexec/bind10/b10-cmdctl
----------------------------------------------------------------------
■やたらプロセスふえたにぃ…

-- 設定の確認とかいろいろ

# /usr/local/bind10/bin/bindctl
----------------------------------------------------------------------
WARNING: Python readline module isn't available, so the command line editor
(including command history management) does not work. See BIND 10
guide for more details.
No stored password file found, please see sections "Configuration specification for b10-cmdctl" and "bindctl command-line options" of the BIND 10 guide.
Username: lapo
Password:
["login success "]
>
----------------------------------------------------------------------
■コマンドヒストリーを見るpythonモジュールがないよ的なメッセージがありますが、
別に今回はキニシナイ
■usernameとpasswordは、"/usr/local/bind10/sbin/b10-cmdctl-usermgr" で作成したものを入力

-- 権威さーばのたちあげ

# /usr/local/bind10/bin/bindctl
> config add Init/components b10-auth
> config set Init/components/b10-auth/special auth
> config set Init/components/b10-auth/kind needed
> config commit
----------------------------------------------------------------------
YYYY-MM-DD HH:MM:SS.068 INFO [b10-init.init/4755] BIND10_CONFIGURATOR_RECONFIGURE reconfiguring running components
YYYY-MM-DD HH:MM:SS.068 INFO [b10-init.init/4755] BIND10_COMPONENT_START component b10-auth is starting
YYYY-MM-DD HH:MM:SS.068 INFO [b10-init.init/4755] BIND10_STARTING_PROCESS starting process b10-auth
YYYY-MM-DD HH:MM:SS.113 INFO [b10-auth.auth/4801] AUTH_SERVER_CREATED server created
YYYY-MM-DD HH:MM:SS.113 INFO [b10-auth.auth/4801] AUTH_DATASRC_CLIENTS_BUILDER_STARTED data source builder thread started
YYYY-MM-DD HH:MM:SS.129 INFO [b10-init.init/4755] BIND10_SOCKET_GET requesting socket [::]:53 of type TCP from the creator
YYYY-MM-DD HH:MM:SS.130 INFO [b10-init.init/4755] BIND10_SOCKET_CREATED successfully created socket 20
YYYY-MM-DD HH:MM:SS.133 INFO [b10-init.init/4755] BIND10_SOCKET_GET requesting socket [::]:53 of type UDP from the creator
YYYY-MM-DD HH:MM:SS.133 INFO [b10-init.init/4755] BIND10_SOCKET_CREATED successfully created socket 22
YYYY-MM-DD HH:MM:SS.135 INFO [b10-init.init/4755] BIND10_SOCKET_GET requesting socket [0.0.0.0]:53 of type TCP from the creator
YYYY-MM-DD HH:MM:SS.135 INFO [b10-init.init/4755] BIND10_SOCKET_CREATED successfully created socket 23
YYYY-MM-DD HH:MM:SS.139 INFO [b10-init.init/4755] BIND10_SOCKET_GET requesting socket [0.0.0.0]:53 of type UDP from the creator
YYYY-MM-DD HH:MM:SS.139 INFO [b10-init.init/4755] BIND10_SOCKET_CREATED successfully created socket 24
YYYY-MM-DD HH:MM:SS.146 INFO [b10-auth.auth/4801] AUTH_DATASRC_CLIENTS_BUILDER_RECONFIGURE_STARTED data source reconfiguration started
YYYY-MM-DD HH:MM:SS.149 INFO [b10-auth.auth/4801] AUTH_SERVER_STARTED server started
YYYY-MM-DD HH:MM:SS.150 WARN [b10-auth.datasrc/4801] DATASRC_SQLITE_SETUP setting up new SQLite3 database in '/usr/local/bind10/var/bind10/zone.sqlite3'
YYYY-MM-DD HH:MM:SS.182 INFO [b10-auth.auth/4801] AUTH_DATASRC_CLIENTS_BUILDER_RECONFIGURE_SUCCESS data source reconfiguration completed successfully
----------------------------------------------------------------------
> quit
■今回は権威サーバが別だてになっているので、これをやらないと権威サーバにならないでふ

-- 名前を引いてみる

dig @127.0.0.1 -c CH -t TXT bind.version
----------------------------------------------------------------------
; <<>> DiG 9.8.3-P1-RedHat-9.8.3-P1.el6 <<>> @127.0.0.1 -c CH -t TXT bind.version
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 48004
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;bind.version. CH TXT
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Feb 25 12:17:38 2013
;; MSG SIZE rcvd: 30
----------------------------------------------------------------------
■;; SERVER: 127.0.0.1#53(127.0.0.1) で、引きにいって、空の内容が帰っているので大丈夫そうな雰囲気

とりあえず何も設定がはいっていないけど、BIND10の権威サーバの立ち上げまではできました。

第二部ではbindctlで設定関連を扱っていきますにぃ

※既存環境(BIND9系)からのアップデートはかなり骨が折れそうな印象

おわり

MySQL5.6 ベンチマーク

2013-02-07T18:40:00.002+09:00

MySQL5.6ベンチマーク

** やったこと
せっかくインストールしたので、いつものmysqlbenchでパフォーマンスちぇーく

** 結果
なかなかやるじゃん！
MariaDBとMySQL5.5よりいいパフォーマンスでました。

**結果比較追記
TOTAL時間の比較結果

1位 MySQL5.6 4419.00 335.79 60.13 395.92 3425950.00
2位 MySQL5.5 5363.00 325.59 55.63 381.22 3425950.00
3位 MariaDB 6539.00 366.44 75.14 441.58 3425950.00

※おまけ
--------------------------------------------------------------------------------
Benchmark DBD suite: 2.15
Date of test: 2013-02-07 17:12:56
Running tests on: Linux 2.6.32-220.23.1.el6.x86_64 x86_64
Arguments:
Comments:
Limits from:
Server version: MySQL 5.6.10 log
Optimization: None
Hardware:

alter-table: Total time: 35 wallclock secs ( 0.08 usr 0.03 sys + 0.00 cusr 0.00 csys = 0.11 CPU)
ATIS: Total time: 36 wallclock secs ( 3.67 usr 0.28 sys + 0.00 cusr 0.00 csys = 3.95 CPU)
big-tables: Total time: 17 wallclock secs ( 1.65 usr 0.34 sys + 0.00 cusr 0.00 csys = 1.99 CPU)
connect: Total time: 112 wallclock secs (31.13 usr 10.90 sys + 0.00 cusr 0.00 csys = 42.03 CPU)
create: Total time: 852 wallclock secs ( 7.83 usr 1.60 sys + 0.00 cusr 0.00 csys = 9.43 CPU)
insert: Total time: 2971 wallclock secs (267.91 usr 43.44 sys + 0.00 cusr 0.00 csys = 311.35 CPU)
select: Total time: 317 wallclock secs (24.57 usr 3.02 sys + 0.00 cusr 0.00 csys = 27.59 CPU)
transactions: Test skipped because the database doesn't support transactions
wisconsin: Total time: 81 wallclock secs ( 2.30 usr 0.64 sys + 0.00 cusr 0.00 csys = 2.94 CPU)

All 9 test executed successfully

Totals per operation:
Operation seconds usr sys cpu tests
alter_table_add 15.00 0.02 0.00 0.02 100
alter_table_drop 16.00 0.01 0.00 0.01 91
connect 7.00 3.27 0.77 4.04 10000
connect+select_1_row 9.00 3.41 0.99 4.40 10000
connect+select_simple 8.00 3.50 0.96 4.46 10000
count 11.00 0.02 0.01 0.03 100
count_distinct 5.00 0.12 0.01 0.13 1000
count_distinct_2 13.00 0.17 0.01 0.18 1000
count_distinct_big 12.00 2.45 0.02 2.47 120
count_distinct_group 9.00 0.44 0.03 0.47 1000
count_distinct_group_on_key 8.00 0.15 0.03 0.18 1000
count_distinct_group_on_key_parts 11.00 0.48 0.02 0.50 1000
count_distinct_key_prefix 5.00 0.15 0.03 0.18 1000
count_group_on_key_parts 10.00 0.44 0.01 0.45 1000
count_on_key 83.00 5.67 0.86 6.53 50100
create+drop 210.00 2.40 0.45 2.85 10000
create_MANY_tables 109.00 1.08 0.22 1.30 10000
create_index 1.00 0.00 0.00 0.00 8
create_key+drop 439.00 2.98 0.51 3.49 10000
create_table 0.00 0.01 0.00 0.01 31
delete_all_many_keys 17.00 0.01 0.00 0.01 1
delete_big 0.00 0.00 0.00 0.00 1
delete_big_many_keys 17.00 0.01 0.00 0.01 128
delete_key 22.00 0.49 0.19 0.68 10000
delete_range 5.00 0.00 0.00 0.00 12
drop_index 0.00 0.00 0.00 0.00 8
drop_table 0.00 0.00 0.01 0.01 28
drop_table_when_MANY_tables 86.00 1.03 0.26 1.29 10000
insert 865.00 15.87 6.16 22.03 350768
insert_duplicates 15.00 3.35 1.25 4.60 100000
insert_key 298.00 5.95 1.81 7.76 100000
insert_many_fields 9.00 0.17 0.03 0.20 2000
insert_select_1_key 4.00 0.00 0.00 0.00 1
insert_select_2_keys 5.00 0.00 0.00 0.00 1
min_max 6.00 0.01 0.00 0.01 60
min_max_on_key 25.00 10.79 1.66 12.45 85000
multiple_value_insert 2.00 0.19 0.01 0.20 100000
once_prepared_select 24.00 5.44 1.58 7.02 100000
order_by_big 10.00 7.25 0.08 7.33 10
order_by_big_key 8.00 6.96 0.04 7.00 10
order_by_big_key2 9.00 7.28 0.06 7.34 10
order_by_big_key_desc 11.00 7.68 0.12 7.80 10
order_by_big_key_diff 10.00 8.15 0.07 8.22 10
order_by_big_key_prefix 9.00 7.25 0.05 7.30 10
order_by_key2_diff 1.00 0.68 0.02 0.70 500
order_by_key_prefix 1.00 0.50 0.01 0.51 500
order_by_range 0.00 0.44 0.01 0.45 500
outer_join 14.00 0.00 0.00 0.00 10
outer_join_found 15.00 0.01 0.00 0.01 10
outer_join_not_found 13.00 0.00 0.00 0.00 500
outer_join_on_key 10.00 0.00 0.00 0.00 10
prepared_select 29.00 10.32 1.57 11.89 100000
select_1_row 16.00 3.43 1.36 4.79 100000
select_1_row_cache 16.00 3.13 1.33 4.46 100000
select_2_rows 16.00 3.38 1.26 4.64 100000
select_big 10.00 7.85 0.00 7.85 80
select_big_str 3.00 1.33 0.30 1.63 10000
select_cache 55.00 1.15 0.17 1.32 10000
select_cache2 54.00 1.15 0.18 1.33 10000
select_column+column 16.00 3.11 1.33 4.44 100000
select_diff_key 0.00 0.07 0.01 0.08 500
select_distinct 2.00 0.61 0.01 0.62 800
select_group 13.00 0.50 0.05 0.55 2911
select_group_when_MANY_tables 8.00 0.34 0.16 0.50 10000
select_join 1.00 0.25 0.00 0.25 100
select_key 56.00 23.10 3.32 26.42 200000
select_key2 64.00 24.12 3.62 27.74 200000
select_key2_return_key 63.00 23.24 3.67 26.91 200000
select_key2_return_prim 63.00 23.75 3.80 27.55 200000
select_key_prefix 65.00 24.17 3.77 27.94 200000
select_key_prefix_join 2.00 1.44 0.01 1.45 100
select_key_return_key 60.00 24.52 3.62 28.14 200000
select_many_fields 8.00 1.47 0.31 1.78 2000
select_range 22.00 2.65 0.08 2.73 410
select_range_key2 7.00 2.41 0.26 2.67 25010
select_range_prefix 7.00 2.29 0.25 2.54 25010
select_simple 11.00 3.42 1.31 4.73 100000
select_simple_cache 10.00 3.15 1.29 4.44 100000
select_simple_join 0.00 0.29 0.02 0.31 500
update_big 20.00 0.00 0.00 0.00 10
update_of_key 129.00 2.28 0.91 3.19 50000
update_of_key_big 16.00 0.03 0.01 0.04 501
update_of_primary_key_many_keys 44.00 0.01 0.01 0.02 256
update_with_key 774.00 12.78 5.52 18.30 300000
update_with_key_prefix 265.00 6.76 2.20 8.96 100000
wisc_benchmark 2.00 1.01 0.07 1.08 114
TOTALS 4419.00 335.79 60.13 395.92 3425950
--------------------------------------------------------------------------------

mysql5.6の幕開け

2013-02-07T12:03:00.001+09:00

mysql5.6の幕開け

** もくてき
mysql5.6が正式リリースされたので、mysql5.5からのアップデートをしてみようというお話

** 環境
いつものさくらVPS1480円プラン
mysql5.5(remiのやつ)インストール済み

** ぱっけーじの取得
http://dev.mysql.com/
ここからパッケージを持ってくる
ダウンロードにはアカウント登録が必要です。
せっかくなので登録しておきませう。

CentOS6でインストールするので、RHEL6用のRPMをもってくる

# ls -1
MySQL-client-5.6.10-1.el6.x86_64.rpm
MySQL-devel-5.6.10-1.el6.x86_64.rpm
MySQL-embedded-5.6.10-1.el6.x86_64.rpm
MySQL-server-5.6.10-1.el6.x86_64.rpm
MySQL-shared-5.6.10-1.el6.x86_64.rpm
MySQL-shared-compat-5.6.10-1.el6.x86_64.rpm
MySQL-test-5.6.10-1.el6.x86_64.rpm

** なにも考えずにインストール

# rpm -ivh MySQL-devel-5.6.10-1.el6.x86_64.rpm \
MySQL-server-5.6.10-1.el6.x86_64.rpm \
MySQL-shared-compat-5.6.10-1.el6.x86_64.rpm \
MySQL-shared-5.6.10-1.el6.x86_64.rpm \
MySQL-client-5.6.10-1.el6.x86_64.rpm
--------------------------------------------------------------------------------
error: Failed dependencies:
mysql-devel conflicts with MySQL-devel-5.6.10-1.el6.x86_64
MySQL-devel conflicts with mysql-devel-5.5.29-1.el6.remi.x86_64
mysql conflicts with MySQL-server-5.6.10-1.el6.x86_64
mysql-server conflicts with MySQL-server-5.6.10-1.el6.x86_64
MySQL conflicts with mysql-5.5.29-1.el6.remi.x86_64
MySQL-server conflicts with mysql-server-5.5.29-1.el6.remi.x86_64
mysql conflicts with MySQL-client-5.6.10-1.el6.x86_64
--------------------------------------------------------------------------------

ですよね。

** 既存のぱっけーじ確認

# yum list installed | grep mysql
--------------------------------------------------------------------------------
compat-mysql51.x86_64 5.1.54-1.el6.remi @remi
mysql.x86_64 5.5.29-1.el6.remi @remi
mysql-bench.x86_64 5.5.29-1.el6.remi @remi
mysql-devel.x86_64 5.5.29-1.el6.remi @remi
mysql-libs.x86_64 5.5.29-1.el6.remi @remi
mysql-server.x86_64 5.5.29-1.el6.remi @remi
--------------------------------------------------------------------------------
# rpm -qa | grep -i mysql
--------------------------------------------------------------------------------
mysql-libs-5.5.29-1.el6.remi.x86_64
mysql-devel-5.5.29-1.el6.remi.x86_64
perl-DBD-MySQL-4.013-3.el6.x86_64
mysql-5.5.29-1.el6.remi.x86_64
mysql-bench-5.5.29-1.el6.remi.x86_64
compat-mysql51-5.1.54-1.el6.remi.x86_64
mysql-server-5.5.29-1.el6.remi.x86_64
--------------------------------------------------------------------------------

** 既存パッケージ削除

# yum remove mysql-libs-5.5.29-1.el6.remi.x86_64 \
mysql-devel-5.5.29-1.el6.remi.x86_64 \
mysql-5.5.29-1.el6.remi.x86_64 \
mysql-server-5.5.29-1.el6.remi.x86_64
===========================================================================================================================================================
Package Arch Version Repository Size
===========================================================================================================================================================
Removing:
mysql x86_64 5.5.29-1.el6.remi @remi 29 M
mysql-devel x86_64 5.5.29-1.el6.remi @remi 598 k
mysql-libs x86_64 5.5.29-1.el6.remi @remi 4.1 M
mysql-server x86_64 5.5.29-1.el6.remi @remi 45 M
Removing for dependencies:
cronie x86_64 1.4.4-7.el6 @anaconda-CentOS-201112091719.x86_64/6.2 166 k
cronie-anacron x86_64 1.4.4-7.el6 @anaconda-CentOS-201112091719.x86_64/6.2 43 k
crontabs noarch 1.10-33.el6 @anaconda-CentOS-201112091719.x86_64/6.2 2.4 k
mysql-bench x86_64 5.5.29-1.el6.remi @remi 2.6 M
postfix x86_64 2:2.6.6-2.2.el6_1 @anaconda-CentOS-201112091719.x86_64/6.2 9.7 M
sysstat x86_64 9.0.4-20.el6 @base 807 k
Transaction Summary
===========================================================================================================================================================
Remove 10 Package(s)
Installed size: 91 M
Is this ok [y/N]:N

** あらためて…。
mysqllibにみっしり依存関係ついてるのは、触った人には有名なお話。
さて、この対応ですが、方法はふたつ。
　1,依存のあるぱっけーじごと消して、後ほど消えた中で必要なものもインストールしなおす
　2,依存をぶったぎって、mysql関連のパッケージのみ削除する
両方メリットデメリットあるけれど、できるのであれば1がお勧めかなーって。
cronの内容とかpostfixのデータとかも、特に吹っ飛ばないし設定に関してもrpmsaveが残るので、
最悪初期設定に戻ったとしても、conf入れ替えてリスタートすればOKだし。
今後依存関係に禍根を残さないという意味で、きれいにしておいて損はないかなーって。

** ということで

# yum remove mysql-libs-5.5.29-1.el6.remi.x86_64 \
mysql-devel-5.5.29-1.el6.remi.x86_64 \
mysql-5.5.29-1.el6.remi.x86_64 \
mysql-server-5.5.29-1.el6.remi.x86_64

再度実行してばっさり。

** インストールりべんじ

# rpm -ivh MySQL-devel-5.6.10-1.el6.x86_64.rpm \
MySQL-server-5.6.10-1.el6.x86_64.rpm \
MySQL-shared-compat-5.6.10-1.el6.x86_64.rpm \
MySQL-shared-5.6.10-1.el6.x86_64.rpm \
MySQL-client-5.6.10-1.el6.x86_64.rpm
--------------------------------------------------------------------------------
Preparing... ########################################### [100%]
1:MySQL-client ########################################### [ 20%]
2:MySQL-shared ########################################### [ 40%]
3:MySQL-shared-compat ########################################### [ 60%]
4:MySQL-server ########################################### [ 80%]
5:MySQL-devel ########################################### [100%]
--------------------------------------------------------------------------------

すんなり。

** もろとも殺されたパッケージたちの再招集

# yum install cronie cronie-anacron crontabs postfix sysstat
--------------------------------------------------------------------------------
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
* epel: ftp.jaist.ac.jp
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package cronie.x86_64 0:1.4.4-7.el6 will be installed
---> Package cronie-anacron.x86_64 0:1.4.4-7.el6 will be installed
---> Package crontabs.noarch 0:1.10-33.el6 will be installed
---> Package postfix.x86_64 2:2.6.6-2.2.el6_1 will be installed
---> Package sysstat.x86_64 0:9.0.4-20.el6 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
===========================================================================================================================================================
Package Arch Version Repository Size
===========================================================================================================================================================
Installing:
cronie x86_64 1.4.4-7.el6 base 70 k
cronie-anacron x86_64 1.4.4-7.el6 base 29 k
crontabs noarch 1.10-33.el6 base 10 k
postfix x86_64 2:2.6.6-2.2.el6_1 base 2.0 M
sysstat x86_64 9.0.4-20.el6 base 225 k
Transaction Summary
===========================================================================================================================================================
Install 5 Package(s)
Total download size: 2.4 M
Installed size: 11 M
Is this ok [y/N]: y
--------------------------------------------------------------------------------

さくっと完了。

** mysqlを起動してみる

# /etc/init.d/mysql start
--------------------------------------------------------------------------------
Starting MySQL. SUCCESS!
--------------------------------------------------------------------------------
# mysql -V
--------------------------------------------------------------------------------
mysql Ver 14.14 Distrib 5.6.10, for Linux (x86_64) using EditLine wrapper
--------------------------------------------------------------------------------

おお。楽ちん。

** かくにん
mysqlのエラーログを確認すると、以下のエラーが。。

--------------------------------------------------------------------------------
2013-02-07 11:33:37 22172 [ERROR] Native table 'performance_schema'.'setup_actors' has the wrong structure
--------------------------------------------------------------------------------

デフォルトで使うでーたべーすの構成変わった？

** mysql_upgradeしてみる

# mysql_upgrade -uroot -p
--------------------------------------------------------------------------------
Enter password:
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
Warning: Using a password on the command line interface can be insecure.
Running 'mysqlcheck with default connection arguments
Warning: Using a password on the command line interface can be insecure.
mysql.columns_priv OK
mysql.db OK
mysql.event OK
mysql.func OK
mysql.general_log OK
mysql.help_category OK
mysql.help_keyword OK
mysql.help_relation OK
mysql.help_topic OK
mysql.host OK
mysql.ndb_binlog_index OK
mysql.plugin OK
mysql.proc OK
mysql.procs_priv OK
mysql.proxies_priv OK
mysql.servers OK
mysql.slow_log OK
mysql.tables_priv OK
mysql.time_zone OK
mysql.time_zone_leap_second OK
mysql.time_zone_name OK
mysql.time_zone_transition OK
mysql.time_zone_transition_type OK
mysql.user OK
test.Bprime OK
test.bench1 OK
test.onek OK
test.tenk1 OK
test.tenk2 OK
Running 'mysql_fix_privilege_tables'...
Warning: Using a password on the command line interface can be insecure.
OK
--------------------------------------------------------------------------------

OKらしい。

** 再起動して確認
# /etc/init.d/mysql restart

--------------------------------------------------------------------------------
Shutting down MySQL.. SUCCESS!
--------------------------------------------------------------------------------
# /etc/init.d/mysql start
--------------------------------------------------------------------------------
Starting MySQL. SUCCESS!
--------------------------------------------------------------------------------

再起動後特に変なエラーもなし。

おわり

MariaDB vs MySQL の仁義なき兄弟対決

2013-02-05T11:47:00.000+09:00

MariaDB vs MySQL の仁義なき兄弟対決

まりあDBって？
mysqlの創始者であらせられるMichael "Monty" Wideniusさんが立ち上げたプロジェクトで作成された
mysqlと完全互換を謳うでーたべーすえんじん。とのこと（wikiを意訳）

理由
次期FedoraやSUSEのデフォルトDBエンジンに採用されるとかなんとかいう噂が聞こえてくる、MariaDB。
お話によるとMySQLの2.7倍のパフォーマンスだとか、1.5倍のパフォーマンスだとかいろいろ聞こえてくるので、
じゃあ一回見てみるかということで、両社の性能対決をしてみようというお話。

これとかで出てますね。
http://it.slashdot.jp/story/13/02/03/0631254/Fedora-19%E3%81%A7%E3%81%AFMySQL%E3%81%AB%E4%BB%A3%E3%81%88%E3%81%A6MariaDB%E3%82%92%E6%8E%A1%E7%94%A8

対決する環境
さくらVPS1480円プラン

* サーバ1
** ミドルウェア
MySQL 5.5.29
mysql-bench 5.5.29
** 設定
yumでいれたまんまのデフォルトのmy.cnf

* サーバ2
** ミドルウェア
MariaDB 5.5.29
mysql-bench 5.5.29
** 設定
設定差をなくすため、１のmy.cnf流用

** 結果

Operation seconds usr sys cpu tests
MySQL ： 5363.00 325.59 55.63 381.22 3425950
MariaDB： 6539.00 366.44 75.14 441.58 3425950

** まとめ

MySQL兄貴の大勝利！
やはり兄より優れた弟は存在しなかったのか・・・？
やっつけな比較なので何とも言えないですが、デフォルト設定同士だと、
MySQLに分があったようですにぃ。

おわり

あとオマケ

MYSQL
--------------------------------------------------------------------------------
Benchmark DBD suite: 2.15
Date of test: 2013-02-05 9:26:33
Running tests on: Linux 2.6.32-220.23.1.el6.x86_64 x86_64
Arguments:
Comments:
Limits from:
Server version: MySQL 5.5.29 MariaDB log
Optimization: None
Hardware:

alter-table: Total time: 79 wallclock secs ( 0.12 usr 0.04 sys + 0.00 cusr 0.00 csys = 0.16 CPU)
ATIS: Total time: 46 wallclock secs ( 3.99 usr 0.34 sys + 0.00 cusr 0.00 csys = 4.33 CPU)
big-tables: Total time: 36 wallclock secs ( 2.62 usr 0.51 sys + 0.00 cusr 0.00 csys = 3.13 CPU)
connect: Total time: 135 wallclock secs (37.48 usr 12.30 sys + 0.00 cusr 0.00 csys = 49.78 CPU)
create: Total time: 485 wallclock secs ( 7.47 usr 2.04 sys + 0.00 cusr 0.00 csys = 9.51 CPU)
insert: Total time: 5170 wallclock secs (291.62 usr 56.01 sys + 0.00 cusr 0.00 csys = 347.63 CPU)
select: Total time: 317 wallclock secs (23.57 usr 2.92 sys + 0.00 cusr 0.00 csys = 26.49 CPU)
transactions: Test skipped because the database doesn't support transactions
wisconsin: Total time: 132 wallclock secs ( 3.21 usr 1.10 sys + 0.00 cusr 0.00 csys = 4.31 CPU)

All 9 test executed successfully

Totals per operation:
Operation seconds usr sys cpu tests
alter_table_add 15.00 0.03 0.00 0.03 100
alter_table_drop 12.00 0.01 0.01 0.02 91
connect 5.00 2.84 0.67 3.51 10000
connect+select_1_row 9.00 4.30 1.06 5.36 10000
connect+select_simple 7.00 3.13 0.78 3.91 10000
count 8.00 0.03 0.00 0.03 100
count_distinct 5.00 0.13 0.03 0.16 1000
count_distinct_2 10.00 0.14 0.02 0.16 1000
count_distinct_big 9.00 2.51 0.05 2.56 120
count_distinct_group 9.00 0.48 0.03 0.51 1000
count_distinct_group_on_key 7.00 0.14 0.01 0.15 1000
count_distinct_group_on_key_parts 7.00 0.40 0.02 0.42 1000
count_distinct_key_prefix 3.00 0.12 0.01 0.13 1000
count_group_on_key_parts 7.00 0.46 0.02 0.48 1000
count_on_key 67.00 6.21 0.86 7.07 50100
create+drop 77.00 1.40 0.37 1.77 10000
create_MANY_tables 61.00 1.11 0.24 1.35 10000
create_index 1.00 0.00 0.00 0.00 8
create_key+drop 101.00 1.81 0.36 2.17 10000
create_table 1.00 0.02 0.00 0.02 31
delete_all_many_keys 195.00 0.02 0.00 0.02 1
delete_big 0.00 0.00 0.00 0.00 1
delete_big_many_keys 195.00 0.02 0.00 0.02 128
delete_key 24.00 0.48 0.12 0.60 10000
delete_range 4.00 0.00 0.00 0.00 12
drop_index 0.00 0.00 0.00 0.00 8
drop_table 0.00 0.00 0.00 0.00 28
drop_table_when_MANY_tables 34.00 0.52 0.15 0.67 10000
insert 1204.00 16.97 5.71 22.68 350768
insert_duplicates 13.00 3.47 1.15 4.62 100000
insert_key 460.00 6.93 1.80 8.73 100000
insert_many_fields 9.00 0.21 0.05 0.26 2000
insert_select_1_key 2.00 0.00 0.00 0.00 1
insert_select_2_keys 3.00 0.00 0.00 0.00 1
min_max 4.00 0.01 0.01 0.02 60
min_max_on_key 18.00 7.95 1.44 9.39 85000
multiple_value_insert 3.00 0.16 0.01 0.17 100000
once_prepared_select 18.00 5.00 1.33 6.33 100000
order_by_big 9.00 6.77 0.09 6.86 10
order_by_big_key 8.00 6.90 0.09 6.99 10
order_by_big_key2 8.00 7.15 0.06 7.21 10
order_by_big_key_desc 10.00 7.09 0.11 7.20 10
order_by_big_key_diff 8.00 6.91 0.08 6.99 10
order_by_big_key_prefix 8.00 7.02 0.06 7.08 10
order_by_key2_diff 2.00 0.87 0.01 0.88 500
order_by_key_prefix 0.00 0.37 0.00 0.37 500
order_by_range 1.00 0.34 0.01 0.35 500
outer_join 11.00 0.00 0.00 0.00 10
outer_join_found 10.00 0.00 0.00 0.00 10
outer_join_not_found 9.00 0.01 0.00 0.01 500
outer_join_on_key 7.00 0.00 0.00 0.00 10
prepared_select 24.00 9.64 1.37 11.01 100000
select_1_row 14.00 3.38 1.27 4.65 100000
select_1_row_cache 12.00 2.85 1.21 4.06 100000
select_2_rows 13.00 3.25 1.14 4.39 100000
select_big 9.00 7.33 0.00 7.33 80
select_big_str 4.00 1.73 0.41 2.14 10000
select_cache 44.00 1.08 0.17 1.25 10000
select_cache2 42.00 1.14 0.16 1.30 10000
select_column+column 15.00 3.40 1.34 4.74 100000
select_diff_key 0.00 0.05 0.01 0.06 500
select_distinct 2.00 0.56 0.02 0.58 800
select_group 9.00 0.55 0.04 0.59 2911
select_group_when_MANY_tables 3.00 0.38 0.15 0.53 10000
select_join 1.00 0.24 0.01 0.25 100
select_key 52.00 22.19 3.98 26.17 200000
select_key2 58.00 25.31 3.43 28.74 200000
select_key2_return_key 52.00 22.41 3.26 25.67 200000
select_key2_return_prim 55.00 24.10 3.38 27.48 200000
select_key_prefix 52.00 22.65 3.05 25.70 200000
select_key_prefix_join 2.00 1.63 0.01 1.64 100
select_key_return_key 53.00 22.98 4.07 27.05 200000
select_many_fields 10.00 1.75 0.27 2.02 2000
select_range 29.00 2.82 0.11 2.93 410
select_range_key2 7.00 2.45 0.26 2.71 25010
select_range_prefix 5.00 2.39 0.28 2.67 25010
select_simple 7.00 2.55 1.14 3.69 100000
select_simple_cache 7.00 2.17 0.87 3.04 100000
select_simple_join 0.00 0.28 0.01 0.29 500
update_big 23.00 0.00 0.00 0.00 10
update_of_key 177.00 2.41 0.80 3.21 50000
update_of_key_big 27.00 0.03 0.01 0.04 501
update_of_primary_key_many_keys 477.00 0.02 0.01 0.03 256
update_with_key 1031.00 13.20 4.61 17.81 300000
update_with_key_prefix 348.00 7.30 1.89 9.19 100000
wisc_benchmark 1.00 0.93 0.07 1.00 114
TOTALS 5363.00 325.59 55.63 381.22 3425950
aag
--------------------------------------------------------------------------------

まりあDB
--------------------------------------------------------------------------------
Benchmark DBD suite: 2.15
Date of test: 2013-02-05 9:26:35
Running tests on: Linux 2.6.32-220.23.1.el6.x86_64 x86_64
Arguments:
Comments:
Limits from:
Server version: MySQL 5.5.29 log
Optimization: None
Hardware:

alter-table: Total time: 31 wallclock secs ( 0.09 usr 0.02 sys + 0.00 cusr 000 csys = 0.11 CPU)
ATIS: Total time: 40 wallclock secs ( 3.86 usr 0.24 sys + 0.00 cusr 0.00 csy = 4.10 CPU)
big-tables: Total time: 19 wallclock secs ( 1.97 usr 0.32 sys + 0.00 cusr 0.0 csys = 2.29 CPU)
connect: Total time: 93 wallclock secs (29.60 usr 9.89 sys + 0.00 cusr 0.00 sys = 39.49 CPU)
create: Total time: 276 wallclock secs ( 5.22 usr 1.27 sys + 0.00 cusr 0.00 sys = 6.49 CPU)
insert: Total time: 4342 wallclock secs (263.28 usr 40.53 sys + 0.00 cusr 0.0 csys = 303.81 CPU)
select: Total time: 278 wallclock secs (22.91 usr 2.89 sys + 0.00 cusr 0.00 sys = 25.80 CPU)
transactions: Test skipped because the database doesn't support transactions
wisconsin: Total time: 109 wallclock secs ( 2.43 usr 0.59 sys + 0.00 cusr 0.0 csys = 3.02 CPU)

All 9 test executed successfully

Totals per operation:
Operation seconds usr sys cpu tests
alter_table_add 38.00 0.02 0.00 0.02 100
alter_table_drop 36.00 0.03 0.01 0.04 91
connect 11.00 5.19 1.34 6.53 10000
connect+select_1_row 20.00 5.99 1.64 7.63 10000
connect+select_simple 12.00 4.99 1.23 6.22 10000
count 9.00 0.02 0.00 0.02 100
count_distinct 5.00 0.15 0.01 0.16 1000
count_distinct_2 10.00 0.16 0.01 0.17 1000
count_distinct_big 11.00 2.87 0.05 2.92 120
count_distinct_group 8.00 0.35 0.02 0.37 1000
count_distinct_group_on_key 7.00 0.14 0.02 0.16 1000
count_distinct_group_on_key_parts 9.00 0.39 0.02 0.41 1000
count_distinct_key_prefix 3.00 0.11 0.02 0.13 1000
count_group_on_key_parts 10.00 0.56 0.02 0.58 1000
count_on_key 72.00 5.58 0.87 6.45 50100
create+drop 125.00 2.19 0.63 2.82 10000
create_MANY_tables 75.00 1.26 0.31 1.57 10000
create_index 1.00 0.00 0.00 0.00 8
create_key+drop 224.00 2.91 0.66 3.57 10000
create_table 1.00 0.01 0.00 0.01 31
delete_all_many_keys 162.00 0.02 0.00 0.02 1
delete_big 0.00 0.01 0.00 0.01 1
delete_big_many_keys 162.00 0.02 0.00 0.02 128
delete_key 32.00 0.54 0.27 0.81 10000
delete_range 14.00 0.00 0.01 0.01 12
drop_index 0.00 0.00 0.00 0.00 8
drop_table 0.00 0.01 0.00 0.01 28
drop_table_when_MANY_tables 57.00 0.74 0.29 1.03 10000
insert 1448.00 23.72 11.02 34.74 350768
insert_duplicates 24.00 5.25 2.03 7.28 100000
insert_key 527.00 8.96 3.21 12.17 100000
insert_many_fields 24.00 0.38 0.08 0.46 2000
insert_select_1_key 9.00 0.00 0.00 0.00 1
insert_select_2_keys 15.00 0.00 0.00 0.00 1
min_max 6.00 0.02 0.01 0.03 60
min_max_on_key 22.00 8.89 1.40 10.29 85000
multiple_value_insert 5.00 0.20 0.02 0.22 100000
once_prepared_select 28.00 6.02 1.54 7.56 100000
order_by_big 10.00 7.37 0.07 7.44 10
order_by_big_key 11.00 9.37 0.11 9.48 10
order_by_big_key2 9.00 7.67 0.08 7.75 10
order_by_big_key_desc 10.00 7.79 0.13 7.92 10
order_by_big_key_diff 8.00 7.22 0.08 7.30 10
order_by_big_key_prefix 10.00 7.38 0.06 7.44 10
order_by_key2_diff 1.00 0.65 0.01 0.66 500
order_by_key_prefix 0.00 0.34 0.01 0.35 500
order_by_range 1.00 0.36 0.00 0.36 500
outer_join 17.00 0.01 0.00 0.01 10
outer_join_found 12.00 0.00 0.00 0.00 10
outer_join_not_found 11.00 0.00 0.00 0.00 500
outer_join_on_key 10.00 0.00 0.00 0.00 10
prepared_select 36.00 12.42 1.72 14.14 100000
select_1_row 19.00 3.81 1.46 5.27 100000
select_1_row_cache 16.00 3.35 1.37 4.72 100000
select_2_rows 19.00 3.88 1.46 5.34 100000
select_big 10.00 8.61 0.06 8.67 80
select_big_str 4.00 1.35 0.33 1.68 10000
select_cache 50.00 1.12 0.16 1.28 10000
select_cache2 51.00 1.18 0.16 1.34 10000
select_column+column 18.00 3.49 1.47 4.96 100000
select_diff_key 0.00 0.05 0.00 0.05 500
select_distinct 2.00 0.51 0.01 0.52 800
select_group 11.00 0.53 0.04 0.57 2911
select_group_when_MANY_tables 4.00 0.37 0.15 0.52 10000
select_join 1.00 0.26 0.00 0.26 100
select_key 61.00 24.28 3.43 27.71 200000
select_key2 68.00 24.69 3.91 28.60 200000
select_key2_return_key 59.00 21.80 3.40 25.20 200000
select_key2_return_prim 64.00 23.51 3.48 26.99 200000
select_key_prefix 60.00 21.69 3.14 24.83 200000
select_key_prefix_join 2.00 1.50 0.02 1.52 100
select_key_return_key 61.00 24.70 3.78 28.48 200000
select_many_fields 11.00 2.23 0.43 2.66 2000
select_range 32.00 2.89 0.08 2.97 410
select_range_key2 6.00 1.88 0.17 2.05 25010
select_range_prefix 7.00 2.39 0.25 2.64 25010
select_simple 9.00 2.90 1.08 3.98 100000
select_simple_cache 7.00 2.53 0.92 3.45 100000
select_simple_join 0.00 0.30 0.01 0.31 500
update_big 70.00 0.00 0.00 0.00 10
update_of_key 241.00 3.07 1.73 4.80 50000
update_of_key_big 53.00 0.06 0.02 0.08 501
update_of_primary_key_many_keys 424.00 0.04 0.01 0.05 256
update_with_key 1286.00 17.99 9.68 27.67 300000
update_with_key_prefix 442.00 10.08 3.77 13.85 100000
wisc_benchmark 3.00 1.12 0.15 1.27 114
TOTALS 6539.00 366.44 75.14 441.58 3425950
--------------------------------------------------------------------------------

PHP5.4+APCのご利用上の注意

2012-09-21T19:55:00.001+09:00

PHP5.4+APCのご利用上の注意

--チューニングのTipsなどなど

経緯

フリーのoptimizerの場合は、eAcceleratorとAPCが有名だけど、eAcceleratorはphp5.4に
対応しておらず、しかたなくAPCを使いますか。という状況になったりする。

ちがい

デフォルトのメモリキャッシュの利用サイズがちがう
⇒APC ：すくなめ(Binaryによって数値が違うけど、remi-testのパッケージだと64M)
⇒eaccelerator：0(無制限)

チューニング

Q,＜メモリの割当て設定を変更しないとパフォーマンスが下がる可能性が
A,APCのキャッシュは固定値を設定する為、サーバの実メモリ容量を超える設定になってしまっている可能性があるよ

たとえば：メモリ4GBのマシンでapacheを運用している場合

Apache子プロセスが1個当たり10MBのメモリを利用しているとして、Maxclient 256にチューニングしてたとする。
APCは子プロセスごとにapc.shm_sizeの数値に従い、メモリを確保するので…
----------------------------------------------------------------------------
今まで
256 * 10MB + もろもろ = 3GBそこそこ < 4GB だった物が、
----------------------------------------------------------------------------
変更後
256 * (10MB + 64MB) + もろもろ = 18.5GBおーばー > 4GB になる
----------------------------------------------------------------------------
こんな感じで、わっさーと溢れる
動きとしてはCPU使用率が少ない割にLoadAvarageが跳ねて、数字の割にコマンドの動作などは軽いような感じ

ということで、
----------------------------------------------------------------------------
チューニング例１
48 * (10MB + 64MB) + もろもろ = 4GB弱くらい > 4GB
処理速度を優先
----------------------------------------------------------------------------
チューニング例２
256 * (10MB + 4MB) + もろもろ = 4GB弱くらい > 4GB
同時アクセス数を優先
----------------------------------------------------------------------------
こんな感じにターゲットを絞って設定をいれてあげる必要がありますよ。と。
こうする事で、CPU使用率とLoadAvarageがシームレスにいい感じなっていきます。

※Apacheの子プロセス自体が利用しているメモリ量は、psコマンド等でRSSの数値を確認してネ

おわり

mysql-mhaを入れてみた！　その２

2012-09-20T18:19:00.005+09:00

mysql-mhaを入れてみた！

ということでー、前回は何も考えずに1サーバの構成で構築をしましたが、
上長構成の意味が無いので、サーバを二台用意してセットアップ。
監視ノードを別のサーバにして上手くいくかどうか。

むしろこっちが本題。

サーバ構成

監視サーバ :MySlaveHost
mysqlサーバ:MyMasterHost

以下作業内容

こんなconfを準備

[root@MySlaveHost ~]# more /etc/app1.cnf
[server default]
# mysql user and password
user=repl
password=repl
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
# master binary-log directory
master_binlog_dir=/var/lib/mysql_s1/data
[server1]
port=3306
hostname=[MyMasterHost's-ip]
[server2]
port=5002
hostname=[MyMasterHost's-ip]
server3]
port=5003
hostname=[MyMasterHost's-ip]

■IPアドレスだけ書き直して、監視サーバに設置

[root@MySlaveHost ~]# masterha_check_repl --conf=/etc/app1.cnf
Tue Jun 26 16:39:14 2012 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Jun 26 16:39:14 2012 - [info] Reading application default configurations from /etc/app1.cnf..
Tue Jun 26 16:39:14 2012 - [info] Reading server configurations from /etc/app1.cnf..
Tue Jun 26 16:39:14 2012 - [info] MHA::MasterMonitor version 0.53.
Tue Jun 26 16:39:14 2012 - [error][/usr/local/share/perl5/MHA/ServerManager.pm, ln622] Master 127.0.0.1:3306 from which slave [MyMasterHost's-ip]([MyMasterHost's-ip]:5003) replicates is not defined in the configuration file!
Tue Jun 26 16:39:14 2012 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln383] Error happend on checking configurations. at /usr/local/share/perl5/MHA/MasterMonitor.pm line 298
Tue Jun 26 16:39:14 2012 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln478] Error happened on monitoring servers.
Tue Jun 26 16:39:14 2012 - [info] Got exit code 1 (Not master dead).
MySQL Replication Health is NOT OK!

■ん・・・？MasterのIPが127.0.0.1になっておる。なぜ？

------------------------------------------------------------------------------------------------------------------------

ということで、ちょっと構成を変えて検証をば。

監視サーバ :MySlaveHost
Master :MyMasterHost(5001)
Slave :MySlaveHost(3306)

[root@MySlaveHost ~]# more /etc/app1.cnf
[server default]
# mysql user and password
user=repl
password=repl
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
# master binary-log directory
master_binlog_dir=/var/lib/mysql_s1/data
[server1]
hostname=MyMasterHost
port=5001
[server2]
hostname=MySlaveHost

■こんな感じにapp1.cnfを変更
------------------------------------------------------------------------------------------------------------------------

[root@MySlaveHost ~]# masterha_check_repl --conf=/etc/app1.cnf
Thu Jun 28 11:18:30 2012 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu Jun 28 11:18:30 2012 - [info] Reading application default configurations from /etc/app1.cnf..
Thu Jun 28 11:18:30 2012 - [info] Reading server configurations from /etc/app1.cnf..
Thu Jun 28 11:18:30 2012 - [info] MHA::MasterMonitor version 0.52.
Thu Jun 28 11:18:30 2012 - [info] Dead Servers:
Thu Jun 28 11:18:30 2012 - [info] Alive Servers:
Thu Jun 28 11:18:30 2012 - [info] MyMasterHost(49.212.145.136:5001)
Thu Jun 28 11:18:30 2012 - [info] MySlaveHost(49.212.133.18:3306)
Thu Jun 28 11:18:30 2012 - [info] Alive Slaves:
Thu Jun 28 11:18:30 2012 - [info] MySlaveHost(49.212.133.18:3306) Version=5.5.25-log (oldest major version between slaves) log-bin:enabled
Thu Jun 28 11:18:30 2012 - [info] Replicating from MyMasterHost(49.212.145.136:5001)
Thu Jun 28 11:18:30 2012 - [info] Current Alive Master: MyMasterHost(49.212.145.136:5001)
Thu Jun 28 11:18:30 2012 - [info] Checking slave configurations..
Thu Jun 28 11:18:30 2012 - [warning] read_only=1 is not set on slave MySlaveHost(49.212.133.18:3306).
Thu Jun 28 11:18:30 2012 - [warning] relay_log_purge=0 is not set on slave MySlaveHost(49.212.133.18:3306).
Thu Jun 28 11:18:30 2012 - [info] Checking replication filtering settings..
Thu Jun 28 11:18:30 2012 - [info] binlog_do_db= , binlog_ignore_db=
Thu Jun 28 11:18:30 2012 - [info] Replication filtering check ok.
Thu Jun 28 11:18:30 2012 - [info] Starting SSH connection tests..
Thu Jun 28 11:18:31 2012 - [info] All SSH connection tests passed successfully.
Thu Jun 28 11:18:31 2012 - [info] Checking MHA Node version..
Thu Jun 28 11:18:31 2012 - [info] Version check ok.
Thu Jun 28 11:18:31 2012 - [info] Checking SSH publickey authentication and checking recovery script configurations on the current master..
Thu Jun 28 11:18:32 2012 - [info] Executing command: save_binary_logs --command=test --start_file=mysql-bin.000024 --start_pos=4 --binlog_dir=/var/lib/mysql_s1/data --output_file=/var/log/masterha/app1/save_binary_logs_test --manager_version=0.52
Thu Jun 28 11:18:32 2012 - [info] Connecting to root@MyMasterHost(MyMasterHost)..
Creating /var/log/masterha/app1 if not exists.. ok.
Checking output directory is accessible or not..
ok.
Binlog found at /var/lib/mysql_s1/data, up to mysql-bin.000024
Thu Jun 28 11:18:32 2012 - [info] Master setting check done.
Thu Jun 28 11:18:32 2012 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Thu Jun 28 11:18:32 2012 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user=repl --slave_host=MySlaveHost --slave_ip=49.212.133.18 --slave_port=3306 --workdir=/var/log/masterha/app1 --target_version=5.5.25-log --manager_version=0.52 --relay_log_info=/var/lib/mysql/data/relay-log.info --slave_pass=xxx
Thu Jun 28 11:18:32 2012 - [info] Connecting to root@49.212.133.18(MySlaveHost)..
Checking slave recovery environment settings..
Opening /var/lib/mysql/data/relay-log.info ... ok.
Relay log found at /var/lib/mysql/data, up to mysqld-relay-bin.000002
Temporary relay log file is /var/lib/mysql/data/mysqld-relay-bin.000002
Testing mysql connection and privileges.. done.
Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Thu Jun 28 11:18:33 2012 - [info] Slaves settings check done.
Thu Jun 28 11:18:33 2012 - [info]
MyMasterHost (current master)
+--MySlaveHost
Thu Jun 28 11:18:33 2012 - [info] Checking replication health on MySlaveHost..
Thu Jun 28 11:18:33 2012 - [info] ok.
Thu Jun 28 11:18:33 2012 - [warning] master_ip_failover_script is not defined.
Thu Jun 28 11:18:33 2012 - [warning] shutdown_script is not defined.
Thu Jun 28 11:18:33 2012 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.

■えっ。。。なんかうまくいってるんですけど・・・
Master-Slaveが同一hostで 3306port 以外の場合はだめってこと？
試しに、以下の構成で確認してみたらだめだった。
Master:MyMasterHost(5001)
Slave1:MySlaveHost(3306)
Slave2:MyMasterHost(5002)
------------------------------------------------------------------------------------------------------------------------

■一応確認
Slave1のportを変えてみる。
以下の構成でも特に問題無く大丈夫だった。なるほどなー。
Master:MyMasterHost(5001)
Slave1:MySlaveHost(5002)

-----------------------------------------------------------------------------------------------------------------------

という事で纏め

だいじょうぶな構成

1,全部一個ですませる
監視ノード→ServerA
DBmaster →ServerA
DBslave →ServerA

2,監視とDBmasterを分ける
監視ノード→ServerB
DBmaster →ServerA
DBslave →ServerB
※MasterとSlaveを別hostにする必要がある

だめな構成

1,監視とDBを分ける
監視ノード→ServerA
DBmaster →ServerB
DBslave →ServerB
※どうやってもMasterのIPアドレスが127.0.0.1になる不具合

上記の挙動は正常なの？バグなの？

おわり

-----------------------------------------------------------------------------------------------------------------------

おまけ的備忘録

毎回わすれる・・・
- ユーザー追加(rootとおなじ権限)
GRANT ALL PRIVILEGES ON *.* TO repl@MySlaveHost IDENTIFIED BY 'repl' WITH GRANT OPTION;

- ユーザー削除
DELETE FROM mysql.user WHERE user='repl' AND host='localhost';

- slave の準備
CHANGE MASTER TO MASTER_HOST = 'MySlaveHost',
MASTER_USER = 'repl',
MASTER_PASSWORD = 'repl',
MASTER_PORT = 5002,
MASTER_LOG_FILE = 'mysql-bin.000004',
MASTER_LOG_POS = 107;

技術者の備忘録

【ゆっくり】WordPress構築動画【AWS】

動画で使ったコマンドの流れ

1,既存パッケージのアップデート

2,Apacheのインストール

3,PHP7.3のインストール

4,mariadbのインストール

5,Apacheとmariadbの起動

6,mariadb上の作業

6-1,ログイン

6-2,データベース作成

6-3,ユーザー作成＆確認

6-4,ユーザー権限の適用

6-5,作成したデータベースの確認

7,wordpress用ユーザーとパスワードでのDB接続確認

8,WordPressの解凍と設置

MySQL8 vs MySQL5.6

やりたいこと

検証環境

お手軽環境準備

負荷試験をかけられる側の環境構築

負荷試験用のテーブルを作成する

負荷試験実施

結果

所感

EFS導入で夢が広がると思ったら、現実を突き付けられた話

xtrabackupをつかったダンプリストア

再起動後にCentOS7でHTTPD2.4が起動しなくなる問題

年末RDSメンテナンスでハマった件

AWS NAT Gatewayがつながらなくて嵌った件

ベンチマークシリーズ Aurora vs MySQL 結果まとめ

ベンチマークシリーズ Aurora vs MySQL

備忘録：gitをプロキシ環境下で使う方法

ansible で playbook を使ってみる

ansibleを使ってみた

NTPパッケージをアップデートしてみる

前提条件

hostsをつくる

playbookをつくる

実行してみる

ansible insall error (ImportError: No module named ansible.runner)

ansibleを触ってみる

こんなエラー

インストールしたときの記憶

確認

python26にパッケージ切替

エラー解消

c3.2xlarge vs c4.2xlarge

Redis hash vs json string

Opensslの脆弱性とその対応

Docker on AWS EC2

Route53がVPCのPrivateDNSに使えるようになったと聞いて

Apache→Fluentd→Redshift でデータ投入する話

RDSでTimezoneを変更するストアドを入れているとMySQL has gone awayされる件

BIND10スタートアップガイド(震え声) vol.1

MySQL5.6 ベンチマーク

mysql5.6の幕開け

MariaDB vs MySQL の仁義なき兄弟対決

PHP5.4+APCのご利用上の注意

PHP5.4+APCのご利用上の注意

経緯

ちがい

チューニング

たとえば：メモリ4GBのマシンでapacheを運用している場合

おわり

mysql-mhaを入れてみた！ その２

mysql-mhaを入れてみた！

サーバ構成

以下作業内容

ということで、ちょっと構成を変えて検証をば。

という事で纏め

だいじょうぶな構成

だめな構成

おまけ的備忘録

mysql-mhaを入れてみた！　その２