ちょっとしたノート

tar コマンドで特定のディレクトリを除外

普段使わないけど、たまに使うときに、あれ？ってなるので、久しぶりにメモ

例えば html/subdir1 と html/subdir2　
を除外してアーカイブを作成したい場合は、--exclude オプションを使う。

tar --exclude='html/subdir1' --exclude='html/subdir2' -cf - html | gzip -c > html.tar.gz

※ --exclude のパスは、tar に渡すパスと相対パスになる

除外対象が多いなら、除外リストをファイルにして

cat > exclude-list.txt <<EOF

html/subdir1

html/subdir2

EOF

tar --exclude-from=exclude-list.txt -cf - html | gzip -c > html.tar.gz

とすることも出来る

httpdを監視

古い環境なだけに面倒なことばっかり起きる

やたら、httpdが元旦に落ちているという謎な現象

そんなわけで、httpdも監視対象にする

vi /etc/monit.d/httpd

check process httpd with pidfile /var/run/httpd/httpd.pid

start program = "/bin/systemctl start httpd" with timeout 60 seconds

stop program = "/bin/systemctl stop httpd"

if failed port 80 for 2 cycles then restart

if failed port 443 for 2 cycles then restart

if 5 restarts within 5 cycles then timeout

check processの行でpidファイルの存在確認。pidファイルが存在しないか、実行中のプロセスのPID番号が含まれていない場合startメソッドを呼び出す。

サービスを起動するコマンド。後ろの「with timeout 60 seconds」は起動タイムアウト時間を指定。

サービスを停止するコマンド。

80ポートへ2回連続でアクセスできなければサービスを再起動する。

443ポートへ2回連続でアクセスできなければサービスを再起動する。

5サイクル中5回再起動が行われた場合にそれ以上再起動を行わず、監視を止める。(再起動できない場合いつまでも再起動を繰り返さない処置です。)

https://www.conversion.co.jp/tecblog/20210107/

MySQL メモ統計情報

前回の記事の対応で、調べたことをメモとして

MySQLでは、テーブルにあるレコードの10%を超えるレコードに
変更を加えられた場合、該当のテーブルの統計情報（カーディナリティ）が再生成される。

構成オプション：innodb_stats_auto_recalcがONの場合。
デフォルトは、ON

Analyzeする場合、
analyze table テーブル名; 以外には、mysqlcheckを使う
（mysqlcheckは、MySQLのテーブルメンテナンス、修復を行なうことができる。

内部的には、CHECK, ANALYZE, REPAIR, OPTIMIZEのコマンドを利用して作業を行ない、

また、MySQLを稼働しているときに、実行することができる。）

全データベースを確認する場合

mysqlcheck -a -u root -p --all-databases

特定データベースのみを確認する場合

mysqlcheck -a DB名 -u root -p

ついでに

check（テーブルのエラーチェック）

全データベースを確認する場合

mysqlcheck -c -u root -p --all-databases

特定データベースのみを確認する場合

mysqlcheck -c DB名 -u root -p

optimize（テーブルの最適化）

全データベースを確認する場合

mysqlcheck -o -u root -p --all-databases

特定データベースのみを確認する場合

mysqlcheck -o DB名 -u root -p

repair（テーブルの修復）

全データベースを修復する場合

mysqlcheck -r -u root -p --all-databases

特定データベースのみを修復する場合

mysqlcheck -r DB名 -u root -p

エラーチェックと修復を組み合わせて実行する場合

mysqlcheck --auto-repair -c -o DB名 -u root -p

MySQL インデックスサイズ

めちゃくちゃハマったので、ここに記載

現行サーバのOSの期限が近付いたため、サーバの移行が行われました。
それにともない、DB（MySQL）も、地味にバージョンアップが実施された。

マイナーバージョンアップにより、SQLが厳密化され、型が違うカラムをJOINの条件にしていた部分をCONVERT()関数をつかって、キャストしたり。。。
CONVERT(数値カラム USING binary)=文字列カラム　みたいな。。。
型を意識しないで結合して作った奴出て来いよ！と思いつつ

それ以外は、プログラムの変更は行われていないのに、サーバ移行が行われ、パフォーマンスが大幅にダウン
その原因究明に、駆り出され、１週間

EXPLAINなどつけて、インデックス状況を確認し、SQLをチューニングしたり
でも、チューニングの結果が出ないの繰り返し。

幸いにも、旧サーバが残っていたので、新旧を比べることに。

新サーバのほうで、今まで使っていたインデックスが効いていない！
なんでだ？なんでだ？と試行錯誤。
（移管した奴が調べろよっと思いつつ、ストレスが溜まる１週間）

推測はインデックスが壊れているでは？、インデックスの統計情報がおかしいのでは？
と思いつつ、壊れているパターンから調査。
壊れてはいなそう。。。ということで、統計情報を確認。

差がありました。。。

確認したSQLとして、
SELECT database_name , table_name , last_update , stat_value , index_name ,
(stat_value * @@innodb_page_size) / 1024 / 1024 as size_mb
FROM mysql.innodb_index_stats
WHERE database_name='データベース名' AND table_name='テーブル名' AND stat_name='size';

結果：size_mbが全然違うじゃん！

ということで、

ANALYZE TABLE テーブル名　を実施

再度、サイズを確認し、更新されたことを確認
プログラムを動かしてみてくれ～とお願いしたら、１秒でレスポンスが返ってきた！と
苦労が報われるお返事がきました。

めちゃくちゃハマったというか、時間を使った。。。

MySQL　tinyintがbooleanになる

cakephp（cakephp3）で、
MySQLで作ったテーブルに、tinyint(1)のカラムを取得してみたところ、
tinyintではなく、booleanになっていた

cakephpの設定が足りないのか？と思いながら、
色々模索していた結果、
MySQLの内部的に、tinyint(1)をbooleanとして使っているとのこと。

JAVAでやっていたときって、こんなことあったっけかな？と思いつつ
んー。。。。って感じです。

つまらないことにハマったので、ここに残す。

Linux CPU負荷やメモリ負荷の履歴

最近、使う機会が増えて、なんだっけ？と思うことが増えてきたので、
ここに残す

普段は使わないsarコマンドで、過去のCPU負荷やメモリ負荷を調べる

サーバにsarコマンドが入っていると、後々救われるということも痛感したので、
もしインストールされていなかったら、インストールしておいたほうがいい。

インストールされているか確認

# rpm -qa | grep sysstat

インストールされていなかったら、インストールする

# yum -y install sysstat

念のためcron設定確認

#cat /etc/cron.d/sysstat

# Run system activity accounting tool every 10 minutes

*/10 * * * * root /usr/lib64/sa/sa1 1 1

# 0 * * * * root /usr/lib64/sa/sa1 600 6 &

# Generate a daily summary of process accounting at 23:53

53 23 * * * root /usr/lib64/sa/sa2 -A

CPUリソースを確認するときは「sar -p」を使用

メモリを確認するときは「sar -r」を使用

sarのデータファイルは/var/log/sa　の中にあり、1ファイル/日で生成され

オプションの-fでファイルを指定する

sar -p -f /var/log/sa/sa02

他のオプション

# sar -A 全情報表示

# sar -q loadaverage

# sar -n DEV 送信／受信パケットに関する情報

# sar -n EDEV エラーパケットに関する情報

# sar -u CPUの利用状況。

# sar -b ディスクI/Oの使用状況

# sar -r メモリとスワップの使用状況

# sar -W 秒当たりのスワップ情報

# sar -s time 指定時間以降のデータ

# sar -e time 指定時間までのデータ

なんだっけ？って思うといつも参考にさせて頂いている
https://every-rating.com/vps/sar.html
https://tech-it.r-net.info/server/command/329/

WSLのUbuntuにLaravel9

WSLのUbuntuにLaravel9環境を作るため

https://qiita.com/y_sone/items/2bf510e551cd14d22042

を参考に構築してました。

構築後に
$./vendor/bin/sail up

と実行した
Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:1025 -> 0.0.0.0:0: listen tcp 0.0.0.0:1025: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

というエラーが。。。
ポート：80 , 3306 なら、直ぐにわかるけど、1025ポートってなんだよ
IISが入っているのか？と思い、調べても入っておらず。

検索しても、なかなかそれらしきものが出てこず、四苦八苦

netstatで調べても、ポート1025を使っているプロセスが見当たらない

Dockerがいけないのかなと思い
$docker compose up -d
を実行すると

WARN[0000] The "WWWGROUP" variable is not set. Defaulting to a blank string.

WARN[0000] The "WWWUSER" variable is not set. Defaulting to a blank string.

[+] Running 5/5

✔ Container example-app-selenium-1 Running 0.0s

✔ Container example-app-redis-1 Running 0.0s

✔ Container example-app-mysql-1 Running 0.0s

✔ Container example-app-meilisearch-1 Running 0.0s

✔ Container example-app-laravel.test-1 Recreated 1.3s

⠋ Container example-app-mailpit-1 Starting 0.0s

Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:1025 -> 0.0.0.0:0: listen tcp 0.0.0.0:1025: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

example-app-mailpit-1 に問題がありそう
docker-compose.ymlのバックアップを取り、docker-compose.ymlを編集
- '${FORWARD_MAILPIT_PORT:-1025}:1025'
となっていた部分を
- '${FORWARD_MAILPIT_PORT:-587}:1025'

と変更して再度、sail up

起動した！！！
結果としては、なんだよって感じだけど、なんで1025が起動しなかったのか
ポートがデフォルト潰されていて、開放しなかったからいけない。とか？

面倒だから、これでいいや

MySQLの実行中SQLを強制終了

mysql コマンドで、mysqlにログイン

show full processlist;

で実行されているSQLの全文が表示される

show full processlist \G;

末尾に\Gを付け加えるとクエリ毎に分割されて、表示される

時間がかかってそうなクエリ、負荷原因のクエリを

kill <プロセスID>

で強制終了させる

MySQL8 ではまったこと

MySQL８では、ちょいちょいハマるので

ユーザのパスワード変更

update mysql.user set password=password('hogehoge') where user = 'mysqluser';

とやっても、ダメ、

password()が使用できなくなっているみたい

方法としては、

USE mysql;

ALTER USER 'mysqluser'@'localhost' identified BY 'hoge';

とやるみたいでした。

PHPからMySQL8接続しようとしたら、

SQLSTATE[HY000][2054] The server requested authentication method unknown to the client

MySQL 8〜ではデフォルトの認証方法が変更になっているようです。

use mysql

select user, host, plugin from user;

pluginが、caching_sha2_passwordとなっているので変更

alter user 'mysqluser'@'localhost' identified with mysql_native_password by 'パスワード';

ここを参考に

mysqldump で件数指定

あまり使う用途はないかもしれないけど

乱暴に記述すると

mysqldump [DB名] --where="true limit 100" > [出力ファイル名]

とすれば、テーブルごとに100件分のデータが、出力ファイルに出力される。

ちゃんと書くなら

mysqldump -h [DBホスト名] -u [DBユーザー名] -p -t [DB名] [テーブル名] --where="true limit [出力件数]" > [出力ファイル名]

ですかね。

ちょっとしたノート

tar コマンドで特定のディレクトリを除外

httpdを監視

MySQL メモ 統計情報

全データベースを確認する場合

特定データベースのみを確認する場合

check（テーブルのエラーチェック）

全データベースを確認する場合

特定データベースのみを確認する場合

optimize（テーブルの最適化）

全データベースを確認する場合

特定データベースのみを確認する場合

repair（テーブルの修復）

全データベースを修復する場合

特定データベースのみを修復する場合

エラーチェックと修復を組み合わせて実行する場合

MySQL インデックスサイズ

MySQL tinyintがbooleanになる

Linux CPU負荷やメモリ負荷の履歴

WSLのUbuntuにLaravel9

MySQLの実行中SQLを強制終了

MySQL8 ではまったこと

mysqldump で件数指定

MySQL メモ統計情報

MySQL　tinyintがbooleanになる