記事を書いている時に前のを参照したくなり、開いたままの一覧から検索を掛けた瞬間エラー。
ブラウザでリロードしたら「データベース接続確立エラー」。
なんだそりゃ？
表（普通にみんなが見ている側ね）から接続してもエラー。
つまり
合掌。
この前MySQLのバージョンを上げたのが原因だろう。
だが、何が悪いのかわからない。
httpdは動いているし、ターミナルで繋ぐことはできるので、ハードの問題ではなさそうだ。
（前にサーバのHDDが死亡したときのことを思い出して嫌な感じはした）
まずアレだ。
ターミナルからMySQLに繋ごう。
# mysql --defaults-extra-file=/hogehoge-conf/mysql_hoge.conf
※これは/hogehoge-conf/に接続ユーザのIDとパスワードを記入したmysql_hoge.confを用意して
ターミナルでパスワードを打たなくても良いようにしている。
まぁどっちにしろコピペで入力するから、あんま変わらんのだけど（何
コネクションエラーで弾かれた。
仕方ない。再起動しよう。
# systemctl restart mysqld
・・・返ってこない。
数分待たされてようやく再起動完了。
Blogにアクセスすると猛烈に遅い。というかやっぱりレスポンスが返ってこない。
明らかにおかしい。
ログを見よう。
[Warning] [MY-012638] [InnoDB] Retry attempts for writing partial data failed.
が大量に出ている。
ナニコレ怖い。
No space left on device
まさかの容量不足！
確かに！
これ、OSをインストールするときに自動にしたら、変な配分にされてルートが猛烈に少なくなったのが原因。
2TBのHDDで1.7TBを何にも割り当てないで放置とか酷すぎだろｗ
結局入れ直すのも面倒なので、一番使うであろうWebサーバのファイル置き場に割り当てた。
当然ルートの配下にある/var/logや/var/lib/mysqlなんかも影響を受けるわけで。
DBの場所を変えて/etc/my.cnfを書き換えても良いんだけど、
影響範囲を調べるのが面倒だから丸っとコピー（移動）してシンボリックリンクを張って終わり。
はい。再起動。
これでひとまず（時々重いが）解決。
調査の中で気になるのを見つけた。容量食い居まくった元凶。
binlog（バイナリログ）さん頑張りすぎ
1GBのファイルを もりもり作りまくって迷惑なんですが。
バイナリログは重要なものなのはわかったけど、俺の環境に必要かというと要らない。
MySQL 8.0ではデフォルトでONになっているので、出力しないように無効化する。
・・・前に要らないログを削除する。
ファイルの物理削除ではなく、MySQL上から行う。
mysql> PURGE MASTER LOGS before now();
残骸はちょっと残るけど、ひとまずスッキリするはず。
じゃ、無効化しましょう。
ついでにコネクション数も増やしておこう。
# vi /etc/my.cnf
max_connections=512
変更後は再起動を忘れずに。
# systemctl restart mysqld
DB関連の必要容量の考慮が甘かったために発生した問題で結構焦ったけど、
不要なファイル（や設定）を除去して、DBデータは広い場所に移動できたので、やり遂げた感は結構あるｗ
これで解決かな？
