-->

2020/01/31

MySQL 的 replication logs 把硬碟空間吃光

今天服務一直中斷,稿不清楚狀況,只是開 console 進機器看,沒看還好,看了嚇一跳,硬碟空間全部被吃光了。

所以先嘗試把可以清空的資料清空:
sudo apt-get autoclean
sudo apt-get clean

cd ~
rm -fr .cache/*

空出了一些空間,但是也大概只有 1 % 左右,所以用 du 掃了一下目錄狀況,發現 /var 佔用超過 10 GB 的空間,這樣目標很明顯了:Docker 或是 MySQL。


先看 Docker,的確不少已經中止不再使用的 container,直接清空:
 $docker system prune
WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all dangling images
        - all dangling build cache
Are you sure you want to continue? [y/N] Y

du 看了一下, /var 還底下還是有一些佔空間的檔案:



找了一下和 log 有關的設定:
max-binlog-size = 128M
innodb-log-file-size = 64M

似乎都沒與此事件無關。不過看到關鍵字「binlog」,查了一下用途,是 master / client 用來同不的 log,應該是我之前抄 DK 的設定檔,抄完忘記把不需要的東西拔乾淨的關係 XD



兇手找到了就不用客氣,把 MySQL replication 的設定全部註解掉。再來登入 MySQL,使用指定把 replication log 全部清乾淨:
purge master logs before now();


2020/01/14

修改專案的 tag (version) 就可以毀掉其他專案

今天剛好要處理 Zip 檔,目前看到功能比較齊全的專案應該是 Ne-Lexa/php-zip,但是用 composer require 時卻發生 error message 大噴發:



仔細一看 .... 居然有「v9.99.99」的版號,該不會要世界末日了吧?


打開 comploser.lock 看一下是怎麼回事,追蹤後得知相依性如下:

laravel v6.10.1  <=  ramsey/uuid ^v3.7

ramsey/uuid  <=  paragonie/random_compat": "^1 | ^2 | 9.99.99"

兇手抓到了,看來在 paragonie/random_compat 有一個版本號是 v9.99.99,composer 會自動拉最新的版本號來使用,因此只要任何專案 require 時沒有指定版本編號,composer 就會自動把相依性對到 v9.99.99,如果其他 package 有關連到,就是直接 dependency conflict 了。


要處理掉這個問題,只要在 composer.json 也 require paragonie/random_compat,但是加上指定版本編號如 ^v2.0,這樣 composer 就只會拉到 v2.x.x 的版本,不會去用 v9.99.99 這個版本。


ref: