概要編から参照されるための詳細編２。
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。
メモリけっこう食う。
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に作ってないから。
あとで作らなあかんなぁ。
root@nafslinux-ubu22:/docker/nariDockerDat# du -shc * | grep maria
5.2G sv_mariadb
2.6G sv_mariadb11
1.8M sv_mariadb11conf
1.8M sv_mariadbconf
root@nafslinux-ubu22:/docker/nariDockerDat#
djangoからの接続を変更
djangoにはsettings.pyってファイルがあって、そこに接続するデータベースのことが書いてあるから変更しておく。
接続先のポート番号だけを変える。
# ローカルデータベース
GV_CONST_HOST = 'nafslinux.intra.gavann-it.com'
GV_CONST_HOST_LCL_HTTP = "http://" + GV_CONST_HOST
GV_CONST_HOST_LCL_HTTPS = "https://" + GV_CONST_HOST
GV_CONST_DOCKER_HTTPS_PORT = "30443"
GV_CONST_DOCKER_HTTP_PORT = "38080"
GV_CONST_DBENVNAME = "nariDB_1st"
GV_CONST_DBUSERNAME = "nari"
GV_CONST_DBPASSWD = "xxxxxx"
GV_CONST_DBPORT = "13306"
#######################################################################
ALLOWED_HOSTS = [GV_CONST_HOST]
# Database
# https://docs.djangoproject.com/en/3.1/ref/settings/#databases
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': GV_CONST_DBENVNAME, # 実際に作ってあるDB名を設定する
'USER': GV_CONST_DBUSERNAME,
'PASSWORD': GV_CONST_DBPASSWD,
'HOST': GV_CONST_HOST,
'PORT': GV_CONST_DBPORT,
'OPTIONS': {
'init_command': "SET sql_mode='STRICT_TRANS_TABLES'",
},
}
}
変更終わったらdjangoのコンテナを再起動する。
docker-composeでの起動の前にsettings.pyの内容をlocal-linux用のもので上書きコピーさせて使ってる箇所もコメント化して新しく書き足す。
DOCKER_ROOT=/docker
DOCKER_CONF1=${DOCKER_ROOT}/nariDockerDat/sv_django-uwsgi-nginx/app/website
DOCKER_CONF2=${DOCKER_ROOT}/nariDockerDat/sv_django-uwsgi-nginx/app/website/static/admin
DOCKER_CONF3=${DOCKER_ROOT}/nariDockerDat/sv_django-uwsgi-nginx/app/templates
cd ${DOCKER_ROOT}
cp -p docker-compose-current.yml docker-compose.yml
## cp -p ${DOCKER_CONF1}/settings-nafslinux.py ${DOCKER_CONF1}/settings.py
cp -p ${DOCKER_CONF1}/settings-nafslinuxMaria1011.py ${DOCKER_CONF1}/settings.py
rm -fR ${DOCKER_CONF2}/commonColor
cp -pR ${DOCKER_CONF2}/commonGreen ${DOCKER_CONF2}/commonColor
cp -p ${DOCKER_CONF3}/Header-nafslinux.html ${DOCKER_CONF3}/Header.html
/usr/local/bin/docker-compose up -d
ステータス表示のアプリを表示させる。一発接続OK。
データベース一覧にテスト用スキーマが存在しないから、新しいほうのデータベースに接続できてる。
あったほうがええと思って、データベースのバージョン表示できるようにあとで変更した。
マスタの科目テーブルもサンプル表示できてるから、読み込みできてるやん。
django管理サイトからの接続
アプリケーションでログイン認証利用してるので、管理サイトにもつなぐ。
１３個の業務テーブル以外に１０個のdjango用テーブルがあるから、その利用確認しとく。
おお、ログインできるやん。
djangoアプリケーションにログイン
django管理サイトにログインするとここでのログインは不要やけど、いったんログアウトしてからdjangoアプリケーションのログイン画面から入ってみる。
当たり前やけど、django管理サイトと同じ認証情報でログインできる。
使えてるやん。
性能の確認
毎月伝票入力して集計させてるのを、「光熱費」とか「通信費」とか毎月発生するものもあるので、例えば3月最初に2月分のデータからコピー作成させてる。
月が変わったら一定のレコード１００件程度を、select insertできるボタンがあるので、実行にかかる体感速度が大きく変わってないか確認する。
3月のデータを手動で削除しとく。
delete from GVIS_keihi where workPeriod > '2023/02/01 0:00:00' ;
delete from GVIS_work where workPeriod > '2023/02/01 0:00:00' ;
次に「コピー作成」ってボタンを押してみる。
5秒以内で終わった。
アプリケーションのログ見たら、ちゃんとsql発行して動いた足跡も残ってる。
普通のデータ入力とblob列へのpdf/jpeg登録
文字や数字、pdf/jpegを登録してみる。
応答速度や一覧表示とかも問題なし。
数年前、mysqlからmariadbに引っ越したとき、日付タイプにnullが許されなくなって、入力画面とか一覧表示でエラー出まくった。
初回登録データの更新日付とかをnullにするのはやめて、「0001年01月01日 0時0分0秒」って手動でデータ書き換えて、phpのデータ操作箇所もnullは使わないように改修したっけ。
今回はそういうことなくてよかったよかった。
金額集計の確認
売上とか経費とか働いた時間を管理してる画面がある。
昔のデータはpdfで保管してて、１円、１時間単位で一致することを確認。
年単位の合計あってた。
月単位の合計も確認。
科目ごとの月合計と横合計も確認。
経費に対するパーセンテージもあってた。
この数字あわせが一致するときって、めっちゃ気持ちいい。
一覧表示やグラフ表示の元は直sql発行した結果を使ってるし、金額あってて、応答速度も問題ない。
10.5から10.11にバージョン上げても問題なさそうかな。
アプリケーションテスト用のスキーマ
djangoでの開発は一段落してるからしばらくは使わんけど、テスト用のスキーマをlocal-linuxの中でだけ維持してる。
新しく何かさせるときに、データをぐちゃぐちゃにいじれる場所。
業務テーブルをコピーしなおせばすぐに復活させられるようにしてる。
同じ要領で作っといた。
テスト用スキーマのバックアップ
local-linuxには毎日動くバックアップ処理があって、その中でテスト用スキーマをフルバックアップする処理がある。
その呼び出し先スクリプトはこんな感じ。
#!/bin/sh
## -------------------------------------------------------------------------
## Script Name :djangoDB11backup.sh
## Created by : T.Naritomi
## on : 2021.11.04
## Updated by :
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments :
## -------------------------------------------------------------------------
## ---detail----------------------------------------------------------------
DOCKER_ROOT=/docker
DJANGO_BACKUP_FROM=/docker/nariDockerDat/sv_mariadb11conf
DJANGO_BACKUP_TO=/docker/nariDockerDat/cl_nari/nariDB_Django
cd ${DOCKER_ROOT}
/usr/bin/docker exec docker-sv_mariadb1011-1 /bin/sh /etc/mysql/conf.d/nari/fullback/3_nariDB_DjangoBackup.sh
chown nari:nari ${DJANGO_BACKUP_FROM}/FullBackup_nariDB_Django.sql
mv -f ${DJANGO_BACKUP_FROM}/FullBackup_nariDB_Django.sql ${DJANGO_BACKUP_TO}/
cat ${DJANGO_BACKUP_FROM}/nari/fullback/3_nariDB_DjangoBackup.sh.res.txt
exit
スクリプトの中からdocker execして3_nariDB_DjangoBackup.shって処理を呼び出してる。
中身はこんな感じ。
mysqldumpでダンプしてる。
mysqlを使ってる頃からの処理をmariadbに切り替えたときに流用して作ったもの。
#!/bin/sh
## -------------------------------------------------------------------------
## Script Name : 3_nariDB_DjangoBackup
## Created by : T.Naritomi
## on : 2021.11.04
## Updated by :
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments :
## -------------------------------------------------------------------------
LANG=ja_JP.UTF-8
TMP_FILE=/tmp/$$_1.txt
RES_FILE=$0.res.txt
DBPASS=xxxxxxxxxx
rm -f ${RES_FILE}
## ----detail --------------------------------------------------------------
## ----FullBackup on MariaDB ---------------------
echo '----DjangoDB full backup Start ------' `date +%F_%T_` >> ${TMP_FILE}
/usr/bin/mysqldump -u root -p${DBPASS} -B nariDB_Django > /etc/mysql/conf.d/FullBackup_nariDB_Django.sql
echo '----DjangoDB full backup Finished-----' `date +%F_%T_` >> ${TMP_FILE}
## ----For MySQL -----------------------------------------------------------
cat ${TMP_FILE} > ${RES_FILE}
chown 999:999 ${RES_FILE}
## ----Finish --------------------------------------------------------------
rm -f ${TMP_FILE}
exit
chownしてるのはmariadbコンテナの中で使われているプロセスオーナのuid。
リストアするときに読めるよう念の為。
右端のプロセスオーナ名は今でもmysqlってなってるなぁ。
nari@nafslinux-ubu22:~$ docker exec -it docker-sv_mariadb1011-1 bash
root@svmariadb1011:/# ps -ef
UID PID PPID C STIME TTY TIME CMD
mysql 1 0 0 05:28 ? 00:00:15 mariadbd
root 89 0 0 06:34 pts/0 00:00:00 bash
root 97 89 0 06:34 pts/0 00:00:00 ps -ef
root@svmariadb1011:/# id mysql
uid=999(mysql) gid=999(mysql) groups=999(mysql)
root@svmariadb1011:/#
フォークして時間経ってるんやしそろそろmysqlじゃないものに変えたらええのに。
テスト用スキーマのバックアップ結果
docker exec経由で動かしたバックアップ結果の最初の数十行はこんな感じ。
-- MariaDB dump 10.19 Distrib 10.11.2-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: localhost Database: nariDB_Django
-- ------------------------------------------------------
-- Server version 10.11.2-MariaDB-1:10.11.2+maria~ubu2204-log
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Current Database: `nariDB_Django`
--
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `nariDB_Django` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci */;
USE `nariDB_Django`;
--
-- Table structure for table `GVIS_keihi`
--
DROP TABLE IF EXISTS `GVIS_keihi`;
テスト用スキーマのリストア
月に何回かgoogle cloudの永続化領域を丸々コピーしてくる。
もちろんgoole cloudの中のmariadb10.11にはテスト用スキーマがない。
丸々コピーしたら、バックアップしてあるテスト用スキーマを戻すけど、このままだと権限がついてない。
手動でやってみるとこんな感じ。
自動でやるときはこんな感じで、リストアする前にバックアップしたダンプファイルの末尾にGRANTの記述を足してる。
#!/bin/sh
## -------------------------------------------------------------------------
## Script Name : djangoDB11restore.sh
## Created by : T.Naritomi
## on : 2023.03.14
## Updated by :
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments :
## -------------------------------------------------------------------------
## ---detail----------------------------------------------------------------
DOCKER_ROOT=/docker
DJANGO_RESTORE_FROM=/docker/nariDockerDat/cl_nari/nariDB_Django/FullBackup_nariDB_Django.sql
DJANGO_RESTORE_TO=/docker/nariDockerDat/sv_mariadb11conf/nari/fullback
cp -pf ${DJANGO_RESTORE_FROM} ${DJANGO_RESTORE_TO}/
echo 'GRANT ALL PRIVILEGES ON `nariDB\_Django`.* TO `nari`@`%` ;' >> ${DJANGO_RESTORE_TO}/`basename ${DJANGO_RESTORE_FROM}`
cd ${DOCKER_ROOT}
/usr/bin/docker exec docker-sv_mariadb1011-1 /bin/sh /etc/mysql/conf.d/nari/fullback/4_nariDB_DjangoRecover.sh
cat ${DJANGO_RESTORE_TO}/4_nariDB_DjangoRecover.sh.res.txt
rm -f ${DJANGO_RESTORE_TO}/`basename ${DJANGO_RESTORE_FROM}`
exit
呼び出され側の4_nariDB_DjangoRecover.shはリストア処理でこんな感じ。
#!/bin/sh
## -------------------------------------------------------------------------
## Script Name : 4_nariDB_DjangoRecover.sh
## Created by : T.Naritomi
## on : 2021.11.04
## Updated by :
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments :
## -------------------------------------------------------------------------
LANG=ja_JP.UTF-8
TMP_FILE=/tmp/$$_1.txt
RES_FILE=$0.res.txt
DBPASS=xxxxxxxx
rm -f ${RES_FILE}
## ----detail --------------------------------------------------------------
## ----Load nariDB_Django on MySQL ---------------------
echo '----fullRecover Start ------' `date +%F_%T_` >> ${TMP_FILE}
/usr/bin/mysql -u root -p${DBPASS} < /etc/mysql/conf.d/nari/fullback/FullBackup_nariDB_Django.sql
echo '----fullRecover Finished-----' `date +%F_%T_` >> ${TMP_FILE}
## ----For MySQL -----------------------------------------------------------
cat ${TMP_FILE} > ${RES_FILE}
## ----Finish --------------------------------------------------------------
rm -f ${TMP_FILE}
exit
テスト用スキーマのリストア結果
単体で動かしてみると、データベースの容量がファイルシステム上で1.3GBほどあっても、リストア処理は1分かからない。バックアップも同じ。
nari@nafslinux-ubu22:/docker$ /bin/sh /docker/djangoDB11restore.sh
----fullRecover Start ------ 2023-03-14_06:46:34_
----fullRecover Finished----- 2023-03-14_06:47:06_
docker-composeの連続可動性確認
ここまでできたら、細かいファイル指定をどうしておけばいいか、本番データのあるgoogle cloudでどうしたらいいかがほぼ確定する。
いったんここまでで作業を停止して、１週間ほどmariadbのコンテナを放置する。
起動・停止して問題出ないかとか、連続稼働時間を長くしてもdocker stasとかでメモリ利用やCPU利用に影響出ないかとか確認しとく。
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
a4364872355c docker-sv_mariadb1011-1 0.03% 1.474GiB / 19.51GiB 7.56% 48.7kB / 17.5MB 1.42GB / 16.4kB 9
4e157ff759b1 docker-cl_ubu22-1 0.00% 10.01MiB / 19.51GiB 0.05% 24.5kB / 0B 20.2MB / 28.7kB 2
f619b8e759d5 docker-cl_red9-1 0.00% 109.7MiB / 19.51GiB 0.55% 13.1MB / 123kB 89MB / 66.2MB 16
b29e82a3cd20 docker-cl_red8-1 0.00% 127.2MiB / 19.51GiB 0.64% 17.5MB / 148kB 93.3MB / 76.9MB 13
dfd6f4319714 svldap-admin 0.02% 65.47MiB / 19.51GiB 0.33% 25.5kB / 0B 57.3MB / 303kB 139
c6e7f9db38ff svldap-server 0.00% 20.94MiB / 19.51GiB 0.10% 51kB / 37kB 26.6MB / 131kB 5
24a58bf2a71f docker-sv_https-portal-1 0.00% 18.04MiB / 19.51GiB 0.09% 26.3kB / 0B 20.8MB / 180kB 14
4fdd5186f555 docker-sv_jupyter-1 0.23% 117.1MiB / 19.51GiB 0.59% 359kB / 423kB 65MB / 53.2kB 4
eb3447c15a0b docker-sv_django-1 0.06% 72.34MiB / 19.51GiB 0.36% 17.5MB / 42.3kB 45.8MB / 16.4kB 11
それほど消費メモリも変わらんなぁ。