カテゴリー: サーバ障害

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

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

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

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

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

MySQL不調からの復帰

7月26日、自宅サーバの apt dist-upgrade をした後から、MySQL の起動で fail するようになった。 そして今日、ようやく直った。 やったことと言えば、apt purge mysql-server やら、rm -rf /var/lib/mysql*  やら、闇雲にこねくり回しただけだった。 原因もわからなければ、どうして復帰できたのかもわからない。謎。

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

さて前回の対応でCPU 100%は回避したものの、バックアップの遅滞が解消されず。 障害は相変わらず発生していて、表面に出てこなくなっただけなのか。 やはりやっつけの対処ではダメなのか。根本的な対策が必要か。しかしどうやって。 「動いているものには手を出すな」確たる根拠のないシステム更新はしたくない。しかしここはもう、それしかなさそうだ。

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

「help! 助けて、acpi_pad 100% で no rsponse 動かない」 help! 助けて、acpi_pad 100% で no rsponse 動かない #linux #ubuntu #ubuntujp — 66式汎用人型工作員ねこパパB型 (@nekopapaZ80) June 14, 2018 こうツイートしたのが、6月14日(木) 09:27。 これによる深刻な障害が発生。当該のサーバをiSCSIのストレージサーバにしており、これをdestinationとしている各サーバのバックアップが極度に遅滞し、想定時間内に終わらないのである。