MySqlのデータディレクトリ移動ではまったのでここに記す

apparmor の usr.sbin.mysqld を書き換え

sudo vim /etc/apparmor.d/usr.sbin.mysqld

書き換え箇所、追加でも上書きでもよい

# Allow data dir access
  /var/lib/mysql/ r,
  /var/lib/mysql/** rwk,
  /home/mysql/ r,
  /home/mysql/** rwk,

mysqld.cnf を書き換え

sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf

書き換え箇所、元の datadir は念の為コメントアウト

#datadir                = /var/lib/mysql
datadir         = /home/mysql

サービスを再起動

sudo service apparmor restart
sudo service mysql restart

障害の数だけ強くなれるよ(3)

例のブツ到着

 2019.04.23(火) 例のブツ発注、2019.04.24(水) 発注したブツ到着、早々に復旧にかかる。

インストールするもの:
Ubuntu 19.04/squid proxy/apache/L2TP(strongswan)/SSL サーバ証明書/sarg/webalizer/PHP/MySQL

“障害の数だけ強くなれるよ(3)” の続きを読む

障害の数だけ強くなれるよ(2)

新機種選定

 ハード障害が確定的となり、さしあたって暫定運用まで復旧し、いよいよ新機種選定となる。非機能要件としては、小型で低消費電力のNUC、機能要件としては、Ubuntu Linuxが動作する、メモリ2GByte以上、ストレージ32GByte以上、e-SATAが1ポート以上あるいはUSB3.0が2ポート以上、加えてキーボードのUSBポートが1以上必要。以上を探してネットを駆け巡る。
 実は旧機は既に8年以上も運用しており、そろそろリプレイスを考えていた。そのため一応の当たりもつけていた。尼損で探すこと数分、適当なものが見つかる。

“障害の数だけ強くなれるよ(2)” の続きを読む

障害の数だけ強くなれるよ(1)

久しぶりのkernel panic

 それは、2019.04.22(月) 17時頃起こった。お家サーバの samba にアクセスできない。帰宅してログを確認、samba 停止。15時頃には発生していた模様。原因不明。
 なんとなく嫌な予感が頭をよぎり、とにかく動いているうちにバックアップを取る(※重要)。バックアップ終了後、サーバを再起動。
 起動中に kernal panic で停止、原因不明。一ヶ月前のシステムバックアップを戻しても起動中に停止、原因不明。とにかく何をどうしても起動しない。先にバックアップを取っておいたことに、安堵する。
状況から、ハードウェア障害(メモリか?)と断定。リプレイスを検討する。

“障害の数だけ強くなれるよ(1)” の続きを読む

MySQL不調からの復帰

7月26日、自宅サーバの apt dist-upgrade をした後から、MySQL の起動で fail するようになった。

そして今日、ようやく直った。

やったことと言えば、apt purge mysql-server やら、rm -rf /var/lib/mysql*  やら、闇雲にこねくり回しただけだった。

原因もわからなければ、どうして復帰できたのかもわからない。謎。

サーバ障害は突然に(2)

さて前回の対応でCPU 100%は回避したものの、バックアップの遅滞が解消されず。

障害は相変わらず発生していて、表面に出てこなくなっただけなのか。

やはりやっつけの対処ではダメなのか。根本的な対策が必要か。しかしどうやって。

「動いているものには手を出すな」確たる根拠のないシステム更新はしたくない。しかしここはもう、それしかなさそうだ。

“サーバ障害は突然に(2)” の続きを読む

サーバ障害は突然に(1)

「help! 助けて、acpi_pad 100% で no rsponse 動かない」

こうツイートしたのが、6月14日(木) 09:27。

これによる深刻な障害が発生。当該のサーバをiSCSIのストレージサーバにしており、これをdestinationとしている各サーバのバックアップが極度に遅滞し、想定時間内に終わらないのである。

“サーバ障害は突然に(1)” の続きを読む