mariadb

TL;DR Zabbixは6.0よりhistoryテーブルに主キーを使うようになりました。server,frontendのパフォーマンス向上とテーブルサイズ削減が見込めるようです。 https://www.zabbix.com/whats_new_6_0#performance_improvements 公式のDockerコンテナを運用している場合、DBコンテナは別なので/usr/share/zabbix-sql-scripts/mysql/history_pk_prepare.sqlがなく、以下から取得したところ、うまくいきました。 https://git.zabbix.com/projects/ZT/repos/rsm-scripts/browse/database/mysql/history_pk_prepare.sql 経緯 Zabbixのダッシュボードのシステム情報に、「データベースのヒストリテーブルが主キーを使用: いいえ」と表示されていることに気づきました。 調べたところ、Zabbix 6.0よりhistoryテーブルの主キーの使用に対応しているとのことでした。 https://www.zabbix.com/whats_new_6_0#performance_improvements 新規に6.0以降をインストールすれば自動で主キーが設定されるが、以前のバージョンのアップグレードの場合は手動で対応する必要があるようです。 https://www.zabbix.com/documentation/6.0/en/manual/appendix/install/db_primary_keys 弊社の環境は公式のDockerコンテナで運用してて、DBはMariaDBの公式Dockerコンテナを使用しています。「MySQL 8.0+ with mysqlsh」の手順に従って進めたところ、途中で指定されている「/usr/share/zabbix-sql-scripts/mysql/history_pk_prepare.sql」が見つかりません。 この手順は1つのサーバーにweb,server,DBをインストールする想定と思われます。公式のDockerコンテナのweb,serverをマウントしてファイル名で検索しても見つからず。 単体のZabbixサーバを構築してファイルを取り出すのも面倒だったのでいろいろ検索し、公式のリポジトリと思われる以下よりダウンロードして流し込んだところ、うまくいきました。 https://git.zabbix.com/projects/ZT/repos/rsm-scripts/browse/database/mysql/history_pk_prepare.sql

TL;DR Ansible Moleculeでのテストの実装はコツがいる 経緯 Ansible MoleculeでAnsibleのroleをテストしたが、結構コツがいるようだったので、メモ。 まず、現時点(2022/9/27)で日本語で言及している記事自体が少ない。以下は参照にさせていただいた。 MoleculeでAnsibleのRoleをテストする - その１ Molecule 3を試す ポイントは以下。 以下の流れで行う(https://molecule.readthedocs.io/en/latest/getting-started.html#run-test-sequence-commands) molecule create (1.Dockerコンテナの生成、起動) molecule converge (2.対象ののロールの実行) molecule verify (3.テスト) molecule destroy molecule testで一連の動作をまとめて実行できるとの記載があるが、自分の環境ではverifyがされていないので利用していない 途中でコケたら、molecule loginでコンテナにログインして実際のコマンドを実行するなどして確認する 1.Dockerコンテナの生成、起動 molecule.ymlを設定する imageにてDockerコンテナのタグを指定する 例えばubuntu:22.04を指定した場合、python3がインストールされていないためにansibleの各種タスクが実行できずにコケる。また、sudoもインストールされていないため、該当のタスクがbecome: yesを指定しているとやはりコケる。対策としてcommandを指定する。 platforms: - name: instance image: ubuntu:22.04 command: - "apt update" - "apt install -y sudo python3" pre_build_image: true 2.対象ののロールの実行 converge.ymlを設定する…が、通常初期値で問題ないはず。他のタスクも実行したい場合は修正が必要なのかも 3.テスト verify.ymlを設定する。 assertタグでうまくいけばTrueとなるよう設定する。ファイルの存在をチェックする場合は以下のような感じ - name: Register if file exists stat: path: "/path/to/file" register: path_to_file - name: Check if file exists ansible....

TL;DR MySQL(MariaDB)の設定ファイルの拡張子は.cnf .confではだめ。includedirでもだめ。 経緯 サーバに直接インストールしていたZabbixを、Raspberry Pi4上のDockerコンテナに移行しました。以前x64上のDockerコンテナで稼働していたことがあるので構築はかんたんに済み、移行もOK。が、併せてZabbixのメジャーバージョンアップを行うとupgrade処理の途中でコケる。日本語を含むデータの変換で失敗している。 show variable like '%char%'を実行すると、system,clinentがlatinになってる… 設定ファイルにはutf8mb4を設定しているのになぜか反映されない。 設定ファイルconf/custom.confを/etc/mysql/conf.dにマウントしていたのだが、VScodede拡張子を.cnfに変えるとVScode上でファイルの認識が変わり、コンテナを再起動すると文字コードが正しく認識された。 公式サイトを見ればわかる話ではあるのですが、htmlファイルを.html,.htmのどちらでも認識するのと同じ感覚で…また、includedirに指定されたフォルダにおいていたので、読んでくれるだろうと思いこんでました。 この設定ファイルは以前Dockerコンテナで運用していた際に使用していたものでしたが、当時からバージョンアップがうまく行かない問題があり、これが原因だった可能性があります。 ちゃんと公式サイトを見ましょうというお話でした。

TL;DR Docker HubにあるMariaDBの公式イメージのメジャーバージョンアップを行う場合、環境変数MARIADB_AUTO_UPGRADEにnon-emptyな値に設定したほうがよい 経緯 Redmineで利用しているMariaDBのバージョンアップを行った。10.4.25から10.6.8に一気に上げた。 途中10.5.15を経由したのだが、その際に以下のメッセージが出たのが気になった。 redmine_db | 2022-06-25 05:16:20+00:00 [Note] [Entrypoint]: MariaDB upgrade (mysql_upgrade) required, but skipped due to $MARIADB_AUTO_UPGRADE setting Docker HubのMariaDB公式サイトを見に行くと確かに以下の記述がある。 Set MARIADB_AUTO_UPGRADE to a non-empty value to have the entrypoint check whether mysql_upgrade/mariadb-upgrade needs to run, and if so, run the upgrade before starting the MariaDB server. Before the upgrade, a backup of the system database is created in the top of the datadir with the name system_mysql_backup_*....

MariaDB: 10.4.12 にて 要約 MariaDB 10.4.12(2020/6/3時点で最新版の1マイナーバージョンだけ前)では、Window関数は ONLY_FULL_GROUP_BY で誤動作する。 内容 MariaDBでROW_NUMBER(), SUM() OVER() 等のWindow関数を使用すると以下のようなエラーが出る。 MySql.Data.MySqlClient.MySqlException: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause Window関数に使用している列をGROUP BYに指定して支障がないところであればそれでクリアできるのだが、そうでないところはどうにもならない。 Window関数自体は10.2から有効なはずなのだが、以下の記事によると、AVGなど一部のWindow関数以外はONLY_FULL_GROUP_BY に対応していないらしい。 https://jira.mariadb.org/browse/MDEV-17785 実際、AVG関数はONLY_FULL_GROUP_BY 制約のもと、GROUP BYで指定しなくても問題なく動作する。ROW_NUMBER(), SUM() はダメ。早く対応してほしい…