Db - Mariadb

mariadbにもLTSってのがある。 11.2が2023年2月に出てた。 MariaDB | endoflife.date endoflife.date 去年の暮れから、そろそろやらなアカンなぁって考えてた。 自分が使ってるのは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に何て書けばいいかが確定する。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +------------------------------------+ |local-linux(ubuntu22) | | +--------------------------------+ | | |docker23 | | | | +--------------+ +-------+ | | | | |mariadb10.5 | |django4| | | | | | nari_1st | <-- | | | | | | | nariDB_Django| | | | | | | +--------------+ +-------+ | | | | | | | | +------------+ | | | | |mariadb10.11| | | | | +------------+ | | | +--------------------------------+ | +------------------------------------+ nari_1stってのが本利用のスキーマでgoogle cloudと同じ内容を維持する。 永続化領域をgoogle cloudから丸々コピーして使ってる。 ...

概要編から参照されるための詳細編１。 local-linuxでmariadb10.11のコンテナを作る docker-composeからビルドと起動できるようにする。 設定ファイルの準備とdocker-compose.ymlの追記 設定ファイルや置き場を用意しながら、mariadb10と11を共存させる。 最近知ったけど、redhat8のアプリケーション管理にはストリームってのがあって、同じアプリでも違うバージョンを共存させられない。 昔はポート番号変えて新旧データベースを共存させられたような気がする。 dockerありがたや。 mariadb本体の設定ファイルの用意 docker単体なら一発起動でええけど、docker-composeでオーケストレーションしてるから、永続化領域にmariadbの設定ファイルとか置いて準備してく。 まずは永続化領域に設定ファイル置き場の作成。 sv_mariadbconfには設定ファイル以外にも、コンテナ内でバックアップとリストアを動かすためのスクリプトが入ってる秘伝のタレみたいなもん。 1 2 cd nariDockerDat cp -pR sv_mariadbconf sv_mariadb11conf djangoからモデル経由でテーブルを扱うとき、pdfとjpegをblob列に保管してる。 設定で必要なのは、この保管ができるようにmax_allowed_packetを書いとく必要がある。 phpで使ってた頃からほぼ内容そのまま。 さっきコピーした内容でそのまま使えるはず。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [mysqld] max_allowed_packet=1024M log_warnings=1 query_cache_size=640M query_cache_type=1 query_cache_limit=1280M innodb_buffer_pool_size=5120M innodb_log_file_size=128M read_buffer_size=320M log-error=/var/log/mariadb.log slow_query_log slow_query_log_file=/var/log/mariadb_slow.log long_query_time=30 innodb_data_file_path=ibdata1:1G innodb_file_per_table=ON [mysqldump] max_allowed_packet=1024M データ置き場と環境変数の用意 dockerで動かすときにはdocker-entrypoint.shとかhealthcheck.shが必要。 ...

概要編から参照されるための詳細編２。 maridb10.11にデータベースコピーする データベースとテーブルを作ってデータを流し込み、django4からの向き先を10.11へ変更する。 django4では集計やグラフ作成させてるから１円単位、１時間単位で数字があってるかを確認してく。 テーブルの作成 空のテーブルを作る。 djangoが管理するテーブルが１０個ある。 前にテーブルの関連性調べた。 管理テーブルにはdjangoアプリケーションへのログイン管理とかが入ってる。 djangoが提供するログインの仕組みを使ってるので自分には必須。 管理テーブルは外部キーを使ってるから、作成順序とデータ投入順位に気を付ける。 その後で自分が設計して利用してる業務テーブル１３個を一括で流す。 10.5で定義を定期的に取ってるので、そのまま流用してcreate tableしてく。 a5sqlで接続してテーブル作成一発OK。 10.5からのコピー djangoが管理するテーブルが１０個あって、さっきcreate tableした順序で１つずつテーブルへデータを流し込む。 a5sqlで最初は全部選択された状態になるけど、いったん「全解除」してから１つずつ管理テーブル選んでコピーする。１つ１分もかからない。 管理テーブルのコピーが終わったら、業務テーブル１３個を一括でコピー。 blob列あるから、複数行インサートは１００行ぐらいを設定しとく。 業務テーブルは5分以内でコピー終わった。 コピーしてるときのdocker statsはこんな感じ。 一番上と一番下が新旧mariadb。 メモリけっこう食う。 1 2 3 4 5 6 7 8 9 10 11 CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS f2e33178380c docker-sv_mariadb1011-1 0.02% 1.67GiB / 19.51GiB 8.56% 1.33GB / 1.13MB 49MB / 2.63GB 11 273c6892b62e docker-cl_red9-1 0.00% 81.16MiB / 19.51GiB 0.41% 31.4kB / 4.98kB 53MB / 34.9MB 15 3c6bdd6634f6 docker-cl_ubu22-1 0.00% 10.43MiB / 19.51GiB 0.05% 23.5kB / 0B 20.8MB / 28.7kB 2 d31718d81aa9 docker-cl_red8-1 0.00% 91.45MiB / 19.51GiB 0.46% 30.4kB / 4.92kB 51.7MB / 35.4MB 12 4fb021b38fcf svldap-admin 0.00% 63.84MiB / 19.51GiB 0.32% 25.9kB / 0B 57MB / 279kB 139 85eb8c870d18 docker-sv_https-portal-1 0.00% 17.96MiB / 19.51GiB 0.09% 27.5kB / 0B 20.6MB / 180kB 14 216fb2fa939a svldap-server 0.00% 20.93MiB / 19.51GiB 0.10% 36.4kB / 14.7kB 26.7MB / 119kB 5 f1ab77ea1fcd docker-sv_jupyter-1 0.22% 98.49MiB / 19.51GiB 0.49% 154kB / 73.2kB 60.9MB / 135kB 1 a1207001c3c1 docker-sv_django-1 0.02% 71.59MiB / 19.51GiB 0.36% 17.5MB / 15.6kB 45.1MB / 16.4kB 11 4a104c3c6ece docker-sv_mariadb-1 0.03% 3.474GiB / 19.51GiB 17.81% 2.64MB / 1.33GB 2.73GB / 2.16MB 12 コピー終わった後の永続化領域の利用サイズ。 sv_mariadbとsv_mariadb11のサイズが倍ぐらい違うのは、アプリケーションテスト用のスキーマをsv_mariadb11に作ってないから。 あとで作らなあかんなぁ。 ...

概要編から参照されるための詳細編３。 google cloudでmariadb10.11.5 local-linuxでやったことと同じことをやってデータベース作る。 当たり前なんやけど、google cloudではCPU・メモリ・ディスクの利用で課金がある。 ディスクは確保したサイズで課金やから毎月同じやけど、CPUとメモリは使った時間で秒単位課金になってる。 金額はそれほど高くないけど、やっぱりアプリケーションを「使う」ために時間を割きたい。 だから構築や変更はできるだけ短い時間で済ませる。そのために開発環境でリハーサルしてるんやし。 gcpで一気に展開 このセクション実施にはlocal-linuxで確認しながら数日かけて実施したけど、gcpの中では1時間程度で完了。 ファイル類の準備と設置 ローカルlinuxで作ったファイルと同じものを用意する。 1 2 3 4 5 6 7 8 9 10 root@gcp-gvis-dklinux:/gvis/nari/nariDocs/Docker/nariDockerDat/sv_mariadb11# ll 合計 56K drwxr-xr-x 3 nari docker 4.0K 2023-03-13 06:59:42 ./ drwxrwxrwx 12 nari naritomitsukasa 4.0K 2023-03-13 06:40:26 ../ drwxr-xr-x 6 lxd 999 4.0K 2023-03-15 06:06:30 data/ -rwxr-xr-x 1 nari docker 20K 2023-03-13 06:41:31 docker-entrypoint.sh* -rw-r--r-- 1 nari docker 131 2023-03-13 06:57:09 env_sv_mariadb11.txt -rwxr-xr-x 1 nari docker 8.6K 2023-03-13 06:41:31 healthcheck.sh* -rw-r--r-- 1 nari docker 6.2K 2023-03-13 06:43:33 sv_mariadb11_Dockerfile root@gcp-gvis-dklinux:/gvis/nari/nariDocs/Docker/nariDockerDat/sv_mariadb11# コンテナ作成と起動 docker-compose.ymlもローカルlinuxで作ったものに準じて用意し起動させる。 フォルダ名や構成もそろえる。 ...

概要編から参照されるための詳細編４。 google cloudでdockerコンテナの永続化領域をgoogle driveへバックアップする コンテナはすべて永続化領域を持たせてる。 前からやってて、業務用の文書やdockerの永続化領域の一部をgoogle driveにzip保管してる。 自分の場合はnariDockerDatってフォルダがその対象。 これをlocal-linuxに展開して使うと、本番データのコピーをいつも使って運用するようになる。 gcpからバックアップの速度 google driveへのzip書き込みはけっこう速い。 gcpの中のxrdpコンテナからrcloneを使ってバックアップするんやけど、rcloneはrsyncみたいな使い勝手でシェルスクリプトから呼び出す。 10GBぐらいのサイズのzipファイルのrclone処理が、3年ぐらい前は10分ぐらいかかってたのが、今は3分もかからない。 https://www.speedtest.net でlocal-linuxのxrdpコンテナが 400〜500Mpbs 出るのが、gcpのxrdpコンテナだと 5000Mbps 速度が出る。 これは、めっちゃくちゃ速い。2022年に測定しなおしたら、また速度上がってた。 測定した数字で１０倍以上、xrdpコンテナ内のfirefoxでgoogle drive開いてもgcpの中だと３倍以上速く感じる。 しかもこの速度、曜日で変動したりしない。 ネットワークの障害とかがなければ、いつも同じ。 けど、嬉しがって何度も使ったらアカン。 gcpへのアップロードは課金ないけど、ダウンロードは課金がある。 それがgoogle driveならgcpからのダウンロードやから、コストがかかる。 自分がgcpを使う理由の１つに、バックアップにかかるコストを低く抑えられることがある。 試験利用したのはかなり昔やけど、gcpからgoogle cloudへのバックアップ速度とコストは、awsと組み合わせたときのものよりも安くて済んだから。 gcpやめられまへんなぁ。 永続化領域保管の前に mariadb10.5から10.11へのバージョンアップがうまくいったので、いったん全コンテナ停止してdocker-compose.ymlから現行のmariadbの記述を外す。 永続化領域も一時的に退避して、新しいほうのmariadbだけが動く状態にしておく。 gcpからコンテナの永続化領域をバックアップ 実際のバックアップ処理。 local-linuxのバックアップ処理を流用して作ってて、利用OSを変更する都度内容更新してる。最近はcentos8からubuntu20へ乗り換えた頃やったかな。 いくつかあるSRC_ROOTから、BACKUP_ROOTへ向けてバックアップして、tar.gzしてからzip化する処理を呼び出す。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 #!/bin/sh ## ------------------------------------------------------------------------- ## Script Name : ## Created by : T.Naritomi ## on : 2007.12.20 ## Updated by : 2019.02.14 ## on : ## Parameters : $1 = password ## Return Code : 0=Normal End ## Comments : ## ------------------------------------------------------------------------- ## ---detail---------------------------------------------------------------- SRC_ROOT=/gvis/nari SRC_ROOT1=/nariDocs/Docker SRC_ROOT2=/gvis/log SRC_ROOT3=/gvis/script SRC_ROOT4=/gvis/nari/nariDocs/gvis_conf SRC_ROOT5=/gvis/nari/nariDocs/smb/common SRC_ROOT6=/gvis/nari/nariDocs/smb/*.html SRC_ROOT7=/nariDocs/smb/svm chmod -R 777 /nari/nariDocs/smb/svm BACKUP_ROOT=/gvis/nari/nariDocs/configBackup/01_gcp-gvis-dkLinux LOG_FILE=/gvis/log/001_sysBackup.log echo "-------Backup Start----" `date +%F_%T_`>> ${LOG_FILE} /usr/bin/docker exec docker-sv_mariadb1011-1 /bin/sh /etc/mysql/conf.d/nari/901_nariDB_1st_DDLout.sh cp -p /gvis/nari/nariDocs/Docker/nariDockerDat/sv_mariadb11conf/nari/DDLdefine.txt /gvis/nari/nariDocs/smb/svm/Public/999_その他/ docker images -f dangling=true -q | xargs docker rmi docker volume ls -qf dangling=true | xargs docker volume rm /bin/sh /gvis/script/301_dockerStop.sh rm -f /gvis/nari/nariDocs/Docker/nariDockerDat/cl_ubun18/backup/*.zip rsync -av --delete --exclude='nariDockerSys/' \ --exclude 'nariDockerDat/cl_ubun18/download/gvis/' \ --exclude 'nariDockerDat/cl_ubun18/download/wk_apl/_old' \ --exclude 'nariDockerDat/cl_ubun18/download/wk_memos/_old' \ --exclude 'nariDockerDat/sv_gitlab2023/' \ --exclude 'nariDockerDat/sv_gitlab2024/' \ ${SRC_ROOT}${SRC_ROOT1}/ ${BACKUP_ROOT}/Docker >> ${LOG_FILE} rm -fR ${BACKUP_ROOT}/log rm -fR ${BACKUP_ROOT}/script rm -fR ${BACKUP_ROOT}/gvis_conf cp -pR ${SRC_ROOT2} ${BACKUP_ROOT}/ cp -pR ${SRC_ROOT3} ${BACKUP_ROOT}/ cp -pR ${SRC_ROOT4} ${BACKUP_ROOT}/ rm -f ${BACKUP_ROOT}/nariDocs/smb/*.html rm -fR ${BACKUP_ROOT}/nariDocs/smb/common cp -pR ${SRC_ROOT5} ${BACKUP_ROOT}/nariDocs/smb/ cp -p ${SRC_ROOT6} ${BACKUP_ROOT}/nariDocs/smb/ rsync -av --delete --exclude='.git/' \ ${SRC_ROOT}${SRC_ROOT7}/ ${BACKUP_ROOT}${SRC_ROOT7} >> ${LOG_FILE} /bin/sh /gvis/script/302_dockerStart.sh /bin/sh /gvis/nari/nariDocs/Docker/dockerStart.sh echo "-------After Backup Docker Start------" `date +%F_%T_`>> ${LOG_FILE} /bin/sh /gvis/script/002_makeTar.sh $1 echo "-------Backup End------" `date +%F_%T_`>> ${LOG_FILE} chown -R nari:nari ${BACKUP_ROOT} /bin/sh /gvis/script/gdr-gavannitsales/003_SyncGavannitsales.sh exit 主な内容。 ...