ブログにも書いたとおり、生前整理の一環として近々現在の自宅を売却し、新たな場所に引っ越して余命尽きるまで賃貸生活をすることに決めました。

ついては本サーバーの自宅運用に引っ越しまでの間サービス断続発生が避けられないことから、サーバーそのものをレンタルサーバーに移行することを検討しました。

その結果、AWSのLightsailサービスが提供するUbuntu OSプレインストールの仮想PC環境に現在使用しているサーバーソフトウェアを移植して完全移行することにしました。

AWSは最初の12ヶ月は無償で評価や環境構築作業が出来るので、その間に移行に伴う技術的な問題を解決していく予定です。

手始めに、Ubuntuをインストールした仮想PCのインスタンスを作成し、リモートから現在使用しているapacheサーバー関連のソースを転送し、ビルドインストールして動作確認済みです。

引き続き、CMS(Xoops)に必要な残りのソースを転送しビルドとインストールを行う予定です。

コンテンツが完全にAWSの仮想PC上に移行できたら、DNSをそちらに切り替え、正式運用する予定です。

んじゃまた。

AWS上のUbuntu 20.04でhttpdが動作したので、次ぎに重要なMySQLを導入しようとしたら躓いた。

sudo apt install mysql-server

を実行すると最後にmysql.serviceを起動する段階で失敗する。

手動でmysqld_safeやmysqldを起動しても立ち上がるが直ぐに終了してしまう。

AWS ubuntu mysqlとかで検索すると、AWSにLAMPを導入する方法に関する質問と回答のページが出てきた。

見ると、データベースはMySQLではなくて、MariaDBになっている。

検索すると、MariaDBはOracleのMySQLの派生らしいことが判明。

今運用しているサーバーは、Debian 3.2とか超ふるいバージョンなので、まだOracle傘下になる前のMySQLが導入されている可能性が高い。

現時点でもOracleはオープンソース版のMySQL(MySQL Community Server)を提供しているので、そちらからUbuntu版をダウンロードすれば使えると思われる。

ただUbuntuのmysql-serverパッケージは提供されているものの、AWSだと起動障害がある状態なのに対して、MariaDBパッケージはすんなり導入できて使えそうな感じ。

なのでCMS側の変更が最小限で済むなら安心なMariDBに移行するのもありかもしれない。

とりあえず、OracleのMySQL Community Serverも試してみる予定。

んじゃまた

OracleからUbuntu 20.4用のMySQL Community Serverのバンドルtar ballをダウンロードして、展開してAWS上のUbuntu 20.04に導入してみたが、驚愕の事実が発覚。

先に正常にインストールできていたMariaDBと一部のパッケージ(ServerとClient)がコンフリクトすることが判明。

なので、MariaDBかMySQL Community Serverどちらかしか使えないことになる。

ということで時代はMariaDBか、CMS側の対応を検討しないとな。

んじゃまた

で、MySQLからMariaDBへの移行を検索してほとんど同じに使えることがわかったので、とりあえず現行のデータベース内容をAWS上のMariaDBにリプリケートすることに。

しかしその前に、MariaDB導入後にMySQLを再導入失敗したのでMySQLの導入済みパッケージを削除していたら途中でコンソールが固まった（；´Д｀）

その後応答なし。

AWDのssh接続はデフォルトでは同時期にひとつに限定されるみたいなので、複数ターミナルを開いて、こっちからそっちへコピー＆ペーストみたいな開発作業はできないぽい。

webの管理ページからrebootを選択したら、瞬時に終わって、変だなと思ったら何も事態は変わっていなかった。

stopを実行したら、startボタンがいつまでたっても復帰しない。

立ち上がらないみたいだな。

メモリが最小の512MBしか割り当てられていないけど、現行サーバーは古いThinkpadのノートPCなので384MBとか中途半端に少ないメモリサイズでも動いている。空きメモリは余裕があったはず。

なんでかな？

またインスタンス作ることから始めないとだめなのか？

んじゃまた

ああ、やっとAWS立ち上がった。

journalctlでkernelログを見たら、MySQLが起動直後に落ちる原因が判明した。

メモリ不足（；´Д｀）

Mar 07 11:12:48 ip-172-26-7-26 kernel: Out of memory: Killed process 201943 (mysqld) tota>

先にメモリ増やさないとだめか。

元々UbuntuのMySQLでもよかったのだな。

んじゃまた

MariaDBが起動失敗する理由がメモリ不足だと判明したので、解決方法は２つある。

(1) メモリがもっと多いインスタンスを現在のインスタンスのsnapshotから作成する
(2) メモリが少ない現在のインスタンスにディスクを追加して、それをswapドライブとして初期化しswaponでswap領域として追加する（メモリ不足時は既に他のプロセスに割り当てられているメモリがバッキングストアに待避され、空いた実メモリが必要なプロセスに再利用されるようにする）

(1)が簡単でAWSもお勧め（しかし増強したインスタンスは無料お試し期間が３ヶ月に短縮される）、rootfsがスナップショットから新インスタンスのrootfsにリストアされるので再度０から構築する必要ない
(2)は追加ディスクは最低容量でも月額0.8USDの費用が追加される

(1),(2)の両方を試してみたがメモリ不足による終了はしなくなったが、どちらも依然としてMariaDBは起動失敗することが判明

なんなんだよ（；´Д｀）

Mar 08 03:25:50 ip-172-26-7-26 systemd[1]: Starting MariaDB 10.3.34 database server...
Mar 08 03:25:50 ip-172-26-7-26 mysqld[6071]: 2022-03-08 3:25:50 0 [Note] /usr/sbin/mysqld (mysqld 10.3.34-MariaDB-0ubuntu0.20.04.1) starting as process 6071 ...
Mar 08 03:25:51 ip-172-26-7-26 audit[6071]: AVC apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=6071 comm="mysqld" requested>
Mar 08 03:25:51 ip-172-26-7-26 kernel: kauditd_printk_skb: 8 callbacks suppressed
Mar 08 03:25:51 ip-172-26-7-26 kernel: audit: type=1400 audit(1646709951.416:98): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify>
Mar 08 03:25:51 ip-172-26-7-26 audit[6071]: AVC apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=6071 comm="mysqld" requested>
Mar 08 03:25:51 ip-172-26-7-26 kernel: audit: type=1400 audit(1646709951.652:99): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify>
Mar 08 03:25:51 ip-172-26-7-26 systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Mar 08 03:25:51 ip-172-26-7-26 sudo[6008]: pam_unix(sudo:session): session closed for user root
Mar 08 03:25:51 ip-172-26-7-26 systemd[1]: mariadb.service: Failed with result 'exit-code'.
Mar 08 03:25:51 ip-172-26-7-26 systemd[1]: Failed to start MariaDB 10.3.34 database server.

systemdのログを見てもmysqldが勝手に落ちたことしか分からないので、その原因を知るために、mysqldのログを調べてみた。

驚愕の事実が判明（´Д｀；）

なんかInnoDBエンジンが存在しないから終了したぽい。

なんだよそれ（´Д｀；）

2022-03-08 3:43:13 0 [Note] InnoDB: Using Linux native AIO
2022-03-08 3:43:13 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-03-08 3:43:13 0 [Note] InnoDB: Uses event mutexes
2022-03-08 3:43:13 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-03-08 3:43:13 0 [Note] InnoDB: Number of pools: 1
2022-03-08 3:43:13 0 [Note] InnoDB: Using SSE2 crc32 instructions
2022-03-08 3:43:13 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instance
s = 1, chunk size = 128M
2022-03-08 3:43:13 0 [Note] InnoDB: Completed initialization of buffer pool
2022-03-08 3:43:13 0 [Note] InnoDB: If the mysqld execution user is authorized, page clea
ner thread priority can be changed. See the man page of setpriority().
2022-03-08 3:43:13 0 [ERROR] InnoDB: Invalid flags 0x4800 in ./ibdata1
2022-03-08 3:43:13 0 [ERROR] InnoDB: Plugin initialization aborted with error Data struct
ure corruption
2022-03-08 3:43:14 0 [Note] InnoDB: Starting shutdown...
2022-03-08 3:43:14 0 [ERROR] Plugin 'InnoDB' init function returned error.
2022-03-08 3:43:14 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2022-03-08 3:43:14 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-03-08 3:43:14 0 [ERROR] Could not open mysql.plugin table. Some plugins may be not l
oaded
2022-03-08 3:43:14 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2022-03-08 3:43:14 0 [ERROR] Aborting

どうやら最初にmysql-serverパッケージをインストールしたのが敗因らしい。

mysql-serverパッケージ導入時に作成される/var/lib/mysql*を削除して、再度mariadb-serverパッケージを導入したら、一度導入途中でsshの接続がフリーズしたが、再接続したら起動成功していたぽい。

インスタンスは2GBメモリ版な。

それでもswapパーティション追加したほうがいいかもな。64bit Linuxだとメモリ使用量も32bit Linuxの倍になると見積もったほうがよさげ。

これで、PHPからアクセスできれば儲けもの。

2022-03-08 4:03:35 0 [Note] InnoDB: Using Linux native AIO
2022-03-08 4:03:35 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-03-08 4:03:35 0 [Note] InnoDB: Uses event mutexes
2022-03-08 4:03:35 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-03-08 4:03:35 0 [Note] InnoDB: Number of pools: 1
2022-03-08 4:03:35 0 [Note] InnoDB: Using SSE2 crc32 instructions
2022-03-08 4:03:35 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instance
s = 1, chunk size = 128M
2022-03-08 4:03:35 0 [Note] InnoDB: Completed initialization of buffer pool
2022-03-08 4:03:35 0 [Note] InnoDB: If the mysqld execution user is authorized, page clea
ner thread priority can be changed. See the man page of setpriority().
2022-03-08 4:03:35 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2022-03-08 4:03:35 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-03-08 4:03:35 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically wri
ting the file full; Please wait ...
2022-03-08 4:03:35 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-03-08 4:03:35 0 [Note] InnoDB: Waiting for purge to start
2022-03-08 4:03:35 0 [Note] InnoDB: 10.3.34 started; log sequence number 1625443; transac
tion id 20
2022-03-08 4:03:35 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-03-08 4:03:35 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_
pool
2022-03-08 4:03:35 0 [Note] InnoDB: Buffer pool(s) load completed at 220308 4:03:35
2022-03-08 4:03:35 0 [Note] Server socket created on IP: '127.0.0.1'.
2022-03-08 4:03:35 0 [Note] Reading of all Master_info entries succeeded
2022-03-08 4:03:35 0 [Note] Added new Master_info '' to hash table
2022-03-08 4:03:35 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.3.34-MariaDB-0ubuntu0.20.04.1' socket: '/run/mysqld/mysqld.sock' port: 3306
Ubuntu 20.04

AWS Lightsailで作成したUbuntuのインスタンスにはAWS Lightsailダッシュボードからブラウザsshターミナルをワンタッチで起動できるのは良いのだけど、注意点が必要。

・Windows PCからだとIEが有効な状態では文字入力がエコーバックされない、Enterのみしか応答しないので、入力できないときはIEが変換モードをトグルして英字モードにする必要あり
・時々原因不明のラグとフリーズを起こす（無償期間のAWSではデフォルト同時接続数は1に制限されるので、現在の接続が完全に切断されないと、新たにsshで接続できなくなる）
・TeraTermのようにscpによるファイル転送とか気の利いた機能はない
・静的IP割り当て（無償）をしないと、インスタンスは起動毎に新しいpublic IPアドレスが割り当てられる（ブラウザssh端末以外の通常のsshターミナルソフトから接続する場合、接続先先を毎回設定しないといけなくなる）

なので、手元のPCからファイル転送したりするためにも、TeraTermを使用していますが、安定して運用できるようになったら静的IPアドレス割り当てを追加しようかと思っています。

現行のサーバーは、プロバイダが割り当てるpublic IPアドレスが変わっても、DNSには定期的に現在のpublic IPアドレスでDNSレコードを自動更新するスクリプトが居るので静的IPアドレスは絶対必要ということはないんだけど、リモートで管理するので今みたいにローカル固定IPアドレスと同じ感覚で使うには静的IPアドレスがあったほうが便利。

んじゃまた。

やっとこさ起動成功したMariaDBをテストしようとしたら、いつの間にか勝手に落ちてた罠（´Д｀；）

やったことと言えば、mysqladminコマンドを起動したぐらいだが。

謎

2022-03-08 4:18:35 0 [Note] /usr/sbin/mysqld (initiated by: unknown): Normal shutdown
2022-03-08 4:18:35 0 [Note] InnoDB: FTS optimize thread exiting.
2022-03-08 4:18:35 0 [Note] Event Scheduler: Purging the queue. 0 events
2022-03-08 4:18:35 0 [Note] InnoDB: Starting shutdown...
2022-03-08 4:18:35 0 [Note] InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_po
ol
2022-03-08 4:18:35 0 [Note] InnoDB: Buffer pool(s) dump completed at 220308 4:18:35
2022-03-08 4:18:36 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2022-03-08 4:18:36 0 [Note] InnoDB: Shutdown completed; log sequence number 1625452; tran
saction id 21
2022-03-08 4:18:36 0 [Note] /usr/sbin/mysqld: Shutdown complete