mariadbにもLTSってのがある。
11.2が2023年2月に出てた。
去年の暮れから、そろそろやらなアカンなぁって考えてた。
自分が使ってるのは10.5.7やったのを10.11に上げてく。
結果的にはバージョンアップするけど、動作確認しながらなので一時的に２つのバージョンのmariadbを共存させる。
去年まではphpから参照してたのを、djangoから参照するように変えたから、django内のモジュールもついでにバージョン上げてく。
詳細は長いリストになるものもあるから、分割で書いてリンク入れといた。
local-linuxとgoogle cloudの環境
local-linuxが練習環境、google cloudにあるのが本番環境。
djangoのアプリケーション作成と同じやり方。
local-linuxでまずは引越しの練習してからgoogle cloudで同じことやって、google cloudのデータをときどきlocal-linuxにもコピー反映する。
google cloudは本番環境として伝票入力とかドキュメント管理に使ってる。
データの入力や保管に「使う」ことに重点を置いてる。
できるだけ計算時間やディスク利用やダウンロードパケットは抑えながら使う方針。
そのためにlocal-linuxで練習してから実施。
実施のイメージ
local-linuxでmariadb10.11のコンテナを作る
docker-composeからビルドと起動できるようにする。
前はDockerfileとかconfフォルダ内の整理ができてなかったから、これもあわせて整理した。
ここでdocker-compose.ymlとdjangoのsettigs.pyに何て書けばいいかが確定する。
+------------------------------------+
|local-linux(ubuntu22) |
| +--------------------------------+ |
| |docker23 | |
| | +--------------+ +-------+ | |
| | |mariadb10.5 | |django4| | |
| | | nari_1st | <-- | | | |
| | | nariDB_Django| | | | |
| | +--------------+ +-------+ | |
| | | |
| | +------------+ | |
| | |mariadb10.11| | |
| | +------------+ | |
| +--------------------------------+ |
+------------------------------------+
nari_1stってのが本利用のスキーマでgoogle cloudと同じ内容を維持する。
永続化領域をgoogle cloudから丸々コピーして使ってる。
nariDB_Djangoってのがdjangoで開発とかテストで使うスキーマで、ローカル環境でだけ維持してる。crontabに登録しておいて毎朝mysqldumpしてて、google cloudからコピーした後はリストアして維持してる。
maridb10.11にデータベースコピーする
データベースとテーブルを作ってデータを流し込み、django4からの向き先を10.11へ変更する。
django4では集計やグラフ作成させてるから１円単位、１時間単位で数字があってるかを確認してく。
+------------------------------------+
|local-linux(ubuntu22) |
| +--------------------------------+ |
| |docker23 | |
| | +--------------+ +-------+ | |
| | |mariadb10.5 | |django4| | |
| | | nari_1st | | | | |
| | | nariDB_Django| | | | |
| | +--------------+ +-------+ | |
| | | | |
| | +--------------+ | | |
| | |mariadb10.11 | | | |
| | | nari_1st | <-------+ | |
| | | nariDB_Django| | |
| | +--------------+ | |
| +--------------------------------+ |
+------------------------------------+
djangoもバージョンアップが早い。
pip3 list -oとかコンテナの中で結果みると、１ヶ月ぐらいで数行出てくる。
去年は開発フェーズやったからホイホイ上げてたけど、今は利用フェーズなのでシーズンごとに更新確認して動作チェック。
google cloudで同じことをやる
local-linuxでやったことと同じことをやってデータベース作る。
ただしnariDB_Djangoってデータベースのスキーマはdjangoのテスト開発用のスキーマやから作らない。
ローカルのwindowsからxrdp-containerに接続して動作確認するけど、明細は省いて合計だけを１円単位、１時間単位で数字があってるか確認してく。
+------------------------------------+
|google cloud(ubuntu22) |
| +--------------------------------+ |
| |docker23 | |
| | +--------------+ +-------+ | |
| | |mariadb10.5 | |django4| | |
| | | nari_1st | | | | |
| | +--------------+ +-------+ | |
| | | | |
| | +--------------+ | | |
| | |mariadb10.11 | | | |
| | | nari_1st | <-------+ | |
| | +--------------+ | |
| | +--------------+ | |
| | |xrdp-container| | |
| | +--------------+ | |
| +--------------------------------+ |
+------------------------------------+
google cloudで永続化領域をgoogle driveへバックアップする
コンテナはすべて永続化領域を持たせてる。
前からやってて、業務用の文書やdockerの永続化領域の一部をgoogle driveにzip保管してる。
自分の場合はnariDockerDatってフォルダがその対象。
gitlabはそもそもバックアップ置き場みたいな扱いなので、バックアップのバックアップは取らない。
この保管の中にあるmariadbの永続化領域をlocal-linuxにコピーして参照利用してる。
２〜３年前と比べるとgoogle cloudからインターネット使うときのデータ転送レートが３倍ぐらいになってて、1500Mbpsとか速度が出るから10GBのzipファイルの転送なんか3分かからずに終わる。
+--------------------------------------------------+
|google cloud(ubuntu22) |
| +--------------------------------+ |
| |docker23 | |
| | +--------------+ +-------+ | |
| | |mariadb10.11 | |django4| | |
| | | nari_1st | <-- | | | |
| | +--------------+ +-------+ | |
| +--------------------------------+ |
| | |
| +--------------------------------+ |
| |nariDockerDat |->Docker.tar.gz| +-------------+
| | django/mariadb | | | |google drive |
| | gitlab | Docker.zip |->| Docker.zip |
| +--------------------------------+ | +-------------+
+--------------------------------------------------+
永続化領域はzipするんじゃなくて、tar.gzにしてる。
こうすると、ファイルの所有権が維持される。
zip化するのはgoogle driveとはいえパスワードをつけて暗号化するため。
dockerは冪等性（べきとうせい）って考え方を具現してて、同じデータを与えたら同じ結果を返す性質がある。
google cloudもlocal-linuxも同じdocker-compose内容で同じイメージを使ったコンテナなら、別のlinuxでも同じ結果を維持してくれるはず。
google driveからlocal-linuxへ永続化領域をコピーして利用
google driveにあるDocker.zipの中からmariadbの永続化領域だけを展開して、mariadb10.11に使わせる。
このとき、crontab経由でdocker execして常時バックアップしてあるnariDB_Djangoの領域をリストアする。
+--------------------------------------------------+
|local-linux(ubuntu22) |
| +--------------------------------+ |
| |docker23 | |
| | +--------------+ +-------+ | |
| | |mariadb10.11 | |django4| | |
| | | nari_1st | <-- | | | |
| | | nariDB_Django| | | | |
| | +--------------+ +-------+ | |
| +--------------------------------+ |
| | |
| +--------------------------------+ |
| |nariDockerDat |<-Docker.tar.gz| +-------------+
| | django/mariadb | | | |google drive |
| | gitlab | | Docker.zip |<-| Docker.zip |
| | | | | +-------------+
| | FullBackup_nariDB_Django.sql | |
| +--------------------------------+ |
+--------------------------------------------------+
google cloudと比べたら宅内lanからインターネットへの速度は500Mbpsぐらいしか出ない。
ダウンロードに5分、zip/tar.gzの展開に5分、それでも10分ぐらいで処理は終わる。
local linuxにあるmariadb10.11の永続化領域内データ置き場はこんな感じ。
nari@nafslinux-ubu22:/docker/nariDockerDat$ ls -lh sv_mariadb11/data
合計 1.2G
-rw-rw---- 1 999 docker 17M 3月 19 04:35 aria_log.00000001
-rw-rw---- 1 999 docker 52 3月 18 09:52 aria_log_control
-rw-rw---- 1 999 docker 16K 3月 19 04:35 ddl_recovery.log
-rw-rw---- 1 999 docker 676K 3月 18 09:52 ib_buffer_pool
-rw-rw---- 1 999 docker 128M 3月 19 04:36 ib_logfile0
-rw-rw---- 1 999 docker 1.0G 3月 19 04:35 ibdata1
-rw-rw---- 1 999 docker 12M 3月 19 03:54 ibtmp1
-rw-rw---- 1 999 docker 0 3月 13 07:03 multi-master.info
drwx------ 2 999 docker 4.0K 3月 13 07:03 mysql
-rw-r--r-- 1 999 docker 15 3月 13 07:03 mysql_upgrade_info
drwx------ 2 999 docker 4.0K 3月 15 07:00 nariDB_1st
drwx------ 2 999 docker 4.0K 3月 19 04:35 nariDB_Django
drwx------ 2 999 docker 4.0K 3月 13 07:03 performance_schema
drwx------ 2 999 docker 12K 3月 13 07:03 sys
nari@nafslinux-ubu22:/docker/nariDockerDat$
思い立ってから、調べながらここまで毎日2時間、10日ぐらいかかった。
7年分の数字確認が一番時間かかったなぁ。
次回のバージョンアップは半分ぐらいの時間で済ませたい。
反省したこと
データベースの引っ越しとかバージョンアップは、いつもけっこう気をつかう。
実務だと、元のデータと移したデータを厳密に比べるとか、サイズ大きいから時間配分に注意するとか。
個人利用でも同じようなことを考えるけど、楽しさとスピードが優先。
起動してスイスイって応答してくれて、数字が一致して、blob列に入れた画像とpdfがスルっと表示できたら嬉しい。
それはだいたい果たせた。
gcp利用金額
特にない。
システム切り替えするときに¥3000を超えなければOK。
local-linuxでだいたい毎月¥2000前後。
普段は10日に1回ほど起動して伝票入力したり、gitlabに登録したりする。
今回はmariadbのバージョン上げて引っ越したのと、確認作業のために5回ぐらい多く起動した。
それでも¥2500で済んで税込み¥2800ぐらいで済んだ。
費用の６割はグラフの青い箇所、ディスク利用。
普段でも¥1200ぐらい行く。
ごく稀にサービス異常で使えなくなることあるけど、2018年頃から使い始めて4年の間、このデータが吹っ飛んだことはないしgcpでサーバ活用すると買い替えとか消耗品交換とか不要やからめっちゃ助かる。
それでも、もうちょっと安くなったらええなぁ。
コンテナがrecreateされた
反省が１つ。
docker-composeずっと使ってる中で、mariadbは自分にとっては根幹機能。
起動順位は真っ先で、ついついノリでymlを書いてるところもあった。
ドキュメント見るとdepends_on使えば起動順位を維持してくれるってある。
ちゃんとそう動いてくれる。
ほとんどのサービス記述にsv_mariadbをsv_mariadb1011に向けて書き換えした。
depends_on:
- sv_mariadb1011
設定変更したら、コンテナは再作成されてもた。
忘れてた。
だいたいのサービスは再作成されてもかまわないけど、ldapとxrdpコンテナは再作成されると面倒くさい。
ldapsの証明書の再配布とか、xrdpのコンテナにaptでブラウザ入れ直しとか。
gcpで確認作業する直前に、コンテナ再作成されてたからaptやりなおしてちょっと時間かかった。
再作成されるとツラいときもあるので、自分で起動順位コントロール。
データベースとldapだけ先に起動させる。
あとはupするときに--no-recreateつけとくか。
/usr/local/bin/docker-compose start sv_mariadb1011
/usr/local/bin/docker-compose start sv_ldap-server
/usr/local/bin/docker-compose up --no-recreate -d
あくまで「起動」するだけで「起動完了」じゃない。
しばらくこのままにして、何か問題あったらsleep入れるかポート開通監視でも入れよっかな。
副作用あるかもしれんけど、こうしとこ。
