Db - Mariadb

概要編から参照されるための詳細編５。 google driveからlocal-linuxへ永続化領域をコピーして利用 google driveにあるDocker.zipの中からmariadbの永続化領域だけを展開して、mariadb10.11に使わせる。 google driveからlocal-linuxへのコピーは自動じゃなく手動。 サイズとか日付とか、ダウンロードの様子見ながらやりたいから。 gcpで入れたのをcyberduckでダウンロード。 さて、ここからlocal-linuxの永続化領域へコピーし、データベース上の開発領域nariDB_Djangoを上書きする。 手動でダウンロードしたもの 置き場は決まってる。 1 2 3 4 5 6 7 8 9 10 11 $ ll 合計 8.7G drwxrwxr-x 2 nari nari 4.0K 2023-01-04 06:46:13 ./ drwxrwxr-x 14 nari nari 4.0K 2022-11-21 05:55:07 ../ -rwxr--r-- 1 nari nari 3.2G 2023-03-18 08:24:07 Docker.zip* -rwxr--r-- 1 nari nari 21M 2023-03-18 08:18:32 gvis_conf.zip* -rwxr--r-- 1 nari nari 1.4M 2023-03-18 08:18:32 log.zip* -rwxr--r-- 1 nari nari 5.5G 2023-03-18 08:28:35 nariDocs.zip* -rwxr--r-- 1 nari nari 15M 2023-03-18 08:18:33 script.zip* nari@nafslinux-ubu22:/nari/nariHTTP/configBackup/ $ unzipして必要なものだけを切り出す windows環境からlocal-linuxの操作やってるので、デスクトップにショートカット作ってバッチ処理経由で展開処理を動かしてる。 ...

母艦として利用してるローカルlinuxも、xrdpコンテナもベースosをjammyからnumbatへ切り替えた。 ローカルkubernetesもminikubeからmicrok8sに切り替えて、利用イメージをnumbatへ切り替えた。 google cloudの中のベースosもxrdpも同じくnumbatへ切り替えた。 面倒やし書かへんけど、業務利用してるawsの中のamazonlinux2023で動かしてるコンテナもnumbatのxrdpに変えてみた。 今月けっこうがんばったな。 もしかしてと思ってdockerhub見たら、mariadbもベースosがnumbatのが出てるやん。 ただ上がるだけやったら放置やけど、LTSが出とる。 コンテナのバージョンアップしたほうがええな。 検証利用やし、メモなしで業務利用のawsの中のmariadbをnumbatにバージョン上げてダンプファイル突っ込んだら、あっさり動いた。 今回は母艦の中のdockerで動いてるmariadbをnumbatに上げる。 mariadbのダンプファイルはテキストになってて、createしたりinsertしたりするからデータの保全はほぼ常にできてる。 バージョンの特定 世間一般へのアナウンスは11.4がLTSってなってた。 MariaDB | endoflife.date endoflife.date dockerhubにタグがあって11.4がある。 hub.docker.com 11.4-nobleは11.4.2ってのと同じdigestになってるから、11.4.2を使えばええっぽい。 11.4.2より新しい11.5ってのもあるけど、LTSやないみたいやから要らん。 ubiってもしや？ なんと、タグ名にubiってのがついてるのがある。 もしかしてUniversalBaseImageの略？　redhatのこととちゃうんか？ ググったら出てきた。 UBI based Docker Official Images - MariaDB.org mariadb.org 「エンタープライズ向けユーザにお知らせでーす」って赤い帽子かぶってるやん。 いろんなプラットフォームで動いてくれるのはええことかなって思う。 サポートの都合でredhat一択っていうユーザ企業もあるやろし。 redhatは母艦にあるubuntuに比べたら、使ってるカーネルが古い傾向があったはず。 dockerは親ホストとコンテナがカーネル共有するから、わけわかめな誤動作出たらイヤやしubiは使わん。 ibmの息がかかったプロダクトはredhat/centosみたいな末路たどるんとちゃうかってイヤな予感。 mysqlがubi使ってもええけど、mariadb大丈夫か？ もしDBMSを切り替えるとしたら、postgresqlでもええけど、あのデータベースは運用途中で勝手に最適化動いて遅くなるのがイマイチ。 何年か前に業務で、javaのガベージコレクションがまとめて動いたときみたいな、悲惨な応答速度になることが夜間バッチであったな。 別のデータベースの可能性を探しながら様子見るしかないな。 どのへんが変わったか データベースそのものを変えるときはsql発行で使えんようになったものとか、使ってる処理に制限が出て影響出えへんかを気にする。 シンプルなsqlだけ使ってたら気にせずでええんやけど、ストアドとか使ってたらdbmsの変更すらできん。 世の中にはこのせいでoracleから抜け出せへんユーザ企業あるやろしな。 同じデータベースで、しかもバージョン変更だけやし、djangoから利用するのが前提やから、それほど気にせずアプリケーションテストでほぼ大丈夫なはずやけど、リリースノートは軽く読む。 MariaDB 11.4.2 Release Notes | MariaDB Documentation mariadb.com けっこういっぱい書いてある。 LTSやししゃぁないんかもしれん。 mysqldumpはmariadb-dumpに変わったんかな。 データの流し込みのとき気をつけなアカンかもな。 真面目に英語読んだのは５行。あとは読む気が萎えた・・・。 バグ対処とかいろいろあるんやろな。 型とかsqlは致命的な変更なさそうに思うけど大丈夫なんかなぁ。 事実を列挙するだけやのうて、使う側目線でもうちょっと読みやすかったらええのに。 どう保全するか 扱ってるデータベースには、djangoアプリからお金の情報/時間の情報/活動記録として数値とテキスト、名刺とか受け取り資料のpdf/jpegがblob列に入ってる。 帳簿は7年分を別途でpdf保管してるから、数字とかテキストを目検で追いかけたり、登録可否を確認する。 古いほうのバージョンのdbmsからのダンプを登録できる(インポート) ７年分の合計金額が１円単位であう(sql集計の確認) djangoのmatplotlibで円グラフ表示させてるパーセンテージが小数点以下でズレてへん(djangoでの集計) 月次の活動記録のテキストとpdf/jpegを任意で拾って化けてたり読み取り不良になってへん(blob列のデコード) mariadbに設定してるmax_allowed_packetを超えへんサイズのpdfがblob列にinsertできる(blob列へのbase64保管) 極端に挙動が遅くなってたりせんか(django画面での応答速度) 意識しながらdjangoの画面を開いて確認やな。 ...

秘伝のタレ mysqlを使ってる頃からあるパラメータ。 今はdockerコンテナでmariadbに移したものを利用。 普段はクラウドの中で動いていて、データとログとパラメータを永続化領域に置いてバックアップしたものを、ローカルdockerの中にそのまま持ってきて環境をクローンしてる。 無効な内容もあるかもしれないけど、時々見直しはしても基本このまま。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [mysqld] max_allowed_packet=2000M 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=200M mysql使い始めの頃はマシンのメモリも8GB程度だったけど、今は20GB程度をdockerに使わせるからチューニングとかしなくなった。 ...

GUIクライアントからロックしてみる 以下のトランザクションを２つの「A5sql」実行窓から順番に動かすと、片方が10秒待った後、もう片方が10秒待って処理が完了する。 1 2 3 4 5 6 7 start transaction ; lock tables GVIS_keihi WRITE ; select sleep(10) ; rollback ; unlock tables ; トランザクションで囲むとプロセス単位で順に処理して内容が維持されるはず。 ロックしてにっちもさっちも行かないとき linux上のmysqlから実行する。 lockの確認 State欄にて「Locked」「updating」等の状態を確認できる。 1 mysql> show processlist; lockしているプロセスの削除 LockedしているプロセスのIdを元にkillを実行。 1 mysql> kill [プロセスId]; テストでふんづまったときや障害のときにやる。