Dockerでmariadbバージョンアップ(詳細編2-mariadb10.11にデータベースコピー)

概要編から参照されるための詳細編2。

maridb10.11にデータベースコピーする

データベースとテーブルを作ってデータを流し込み、django4からの向き先を10.11へ変更する。

django4では集計やグラフ作成させてるから1円単位、1時間単位で数字があってるかを確認してく。

テーブルの作成

空のテーブルを作る。

djangoが管理するテーブルが10個ある。前にテーブルの関連性調べた。

管理テーブルにはdjangoアプリケーションへのログイン管理とかが入ってる。
djangoが提供するログインの仕組みを使ってるので自分には必須。

管理テーブルは外部キーを使ってるから、作成順序とデータ投入順位に気を付ける。

その後で自分が設計して利用してる業務テーブル13個を一括で流す。

10.5で定義を定期的に取ってるので、そのまま流用してcreate tableしてく。

gvis-docker-mariadb11

a5sqlで接続してテーブル作成一発OK。

10.5からのコピー

djangoが管理するテーブルが10個あって、さっきcreate tableした順序で1つずつテーブルへデータを流し込む。

gvis-docker-mariadb11

a5sqlで最初は全部選択された状態になるけど、いったん「全解除」してから1つずつ管理テーブル選んでコピーする。1つ1分もかからない。

管理テーブルのコピーが終わったら、業務テーブル13個を一括でコピー。
blob列あるから、複数行インサートは100行ぐらいを設定しとく。

gvis-docker-mariadb11

業務テーブルは5分以内でコピー終わった。

gvis-docker-mariadb11

コピーしてるときの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。

gvis-docker-mariadb11

データベース一覧にテスト用スキーマが存在しないから、新しいほうのデータベースに接続できてる。

あったほうがええと思って、データベースのバージョン表示できるようにあとで変更した。

マスタの科目テーブルもサンプル表示できてるから、読み込みできてるやん。

gvis-docker-mariadb11

django管理サイトからの接続

アプリケーションでログイン認証利用してるので、管理サイトにもつなぐ。
13個の業務テーブル以外に10個のdjango用テーブルがあるから、その利用確認しとく。

gvis-docker-mariadb11

おお、ログインできるやん。

gvis-docker-mariadb11

djangoアプリケーションにログイン

django管理サイトにログインするとここでのログインは不要やけど、いったんログアウトしてからdjangoアプリケーションのログイン画面から入ってみる。

gvis-docker-mariadb11

当たり前やけど、django管理サイトと同じ認証情報でログインできる。
使えてるやん。

gvis-docker-mariadb11

性能の確認

毎月伝票入力して集計させてるのを、「光熱費」とか「通信費」とか毎月発生するものもあるので、例えば3月最初に2月分のデータからコピー作成させてる。

月が変わったら一定のレコード100件程度を、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' ;

次に「コピー作成」ってボタンを押してみる。

gvis-docker-mariadb11

5秒以内で終わった。
アプリケーションのログ見たら、ちゃんとsql発行して動いた足跡も残ってる。

gvis-docker-mariadb11

普通のデータ入力とblob列へのpdf/jpeg登録

文字や数字、pdf/jpegを登録してみる。

gvis-docker-mariadb11

応答速度や一覧表示とかも問題なし。

数年前、mysqlからmariadbに引っ越したとき、日付タイプにnullが許されなくなって、入力画面とか一覧表示でエラー出まくった。

初回登録データの更新日付とかをnullにするのはやめて、「0001年01月01日 0時0分0秒」って手動でデータ書き換えて、phpのデータ操作箇所もnullは使わないように改修したっけ。

今回はそういうことなくてよかったよかった。

金額集計の確認

売上とか経費とか働いた時間を管理してる画面がある。
昔のデータはpdfで保管してて、1円、1時間単位で一致することを確認。

gvis-docker-mariadb11

年単位の合計あってた。
月単位の合計も確認。

gvis-docker-mariadb11

科目ごとの月合計と横合計も確認。

gvis-docker-mariadb11

経費に対するパーセンテージもあってた。
この数字あわせが一致するときって、めっちゃ気持ちいい。

一覧表示やグラフ表示の元は直sql発行した結果を使ってるし、金額あってて、応答速度も問題ない。

10.5から10.11にバージョン上げても問題なさそうかな。

アプリケーションテスト用のスキーマ

djangoでの開発は一段落してるからしばらくは使わんけど、テスト用のスキーマをlocal-linuxの中でだけ維持してる。

新しく何かさせるときに、データをぐちゃぐちゃにいじれる場所。
業務テーブルをコピーしなおせばすぐに復活させられるようにしてる。

同じ要領で作っといた。

gvis-docker-mariadb11

テスト用スキーマのバックアップ

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にはテスト用スキーマがない。

丸々コピーしたら、バックアップしてあるテスト用スキーマを戻すけど、このままだと権限がついてない。

手動でやってみるとこんな感じ。

gvis-docker-mariadb11

自動でやるときはこんな感じで、リストアする前にバックアップしたダンプファイルの末尾に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でどうしたらいいかがほぼ確定する。

いったんここまでで作業を停止して、1週間ほど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

それほど消費メモリも変わらんなぁ。

コメント