MariaDB10.8.3が2022年5月にGAになりました。
https://mariadb.com/kb/en/mariadb-1083-release-notes/
10.7のときに見落としていたのですが、
10.7も10.8もshort term supportのようで、
サポート期間はリリースから1年のようです。
直近では、10.6がLTSという扱いのようです。
機能概要は以下のとおりです。
https://mariadb.com/kb/en/changes-improvements-in-mariadb-108/
個人的に気になった点だけ挙げておきます。
（LAG free ALTER）
レプリケーションをしていると、ALTER TABLEはまずプライマリ（マスター）で実行され、
完了してはじめて、レプリカ（スレーブ）に伝播するというものでした。
そのため、大きなテーブルでALTERを実行すると、レプリカの遅延が激しくなっていました。
（プライマリでALTER開始〜完了）→レプリケーション→（レプリカでALTER開始〜完了）
って感じが従来の流れですね。
で、今回の機能により、
（プライマリでALTER開始）→レプリケーション→（レプリカでALTER開始）→（プライマリ・レプリカでALTER完了）
って感じになるため、レプリカ遅延、つまりラグがおきにくいですよ、って話かと。
昔MySQLで巨大なテーブルにALTERしたら、マスターで2時間、スレーブで2時間、
合計4時間とかになったことがあったので、
これが合わせて2時間で終わる感じになるので、とても素敵な機能かと思います。
（JSON Histgrams）
histgramの結果を格納しているmysql.column_statsテーブルが変更になりました。
10.4
> desc mysql.column_stats;
+---------------+-----------------------------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+-----------------------------------------+------+-----+---------+-------+
| db_name | varchar(64) | NO | PRI | NULL | |
| table_name | varchar(64) | NO | PRI | NULL | |
| column_name | varchar(64) | NO | PRI | NULL | |
| min_value | varbinary(255) | YES | | NULL | |
| max_value | varbinary(255) | YES | | NULL | |
| nulls_ratio | decimal(12,4) | YES | | NULL | |
| avg_length | decimal(12,4) | YES | | NULL | |
| avg_frequency | decimal(12,4) | YES | | NULL | |
| hist_size | tinyint(3) unsigned | YES | | NULL | |
| hist_type | enum('SINGLE_PREC_HB','DOUBLE_PREC_HB') | YES | | NULL | |
| histogram | varbinary(255) | YES | | NULL | |
+---------------+-----------------------------------------+------+-----+---------+-------+
10.8
> desc mysql.column_stats;
+---------------+---------------------------------------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------------------------------------------------+------+-----+---------+-------+
| db_name | varchar(64) | NO | PRI | NULL | |
| table_name | varchar(64) | NO | PRI | NULL | |
| column_name | varchar(64) | NO | PRI | NULL | |
| min_value | varbinary(255) | YES | | NULL | |
| max_value | varbinary(255) | YES | | NULL | |
| nulls_ratio | decimal(12,4) | YES | | NULL | |
| avg_length | decimal(12,4) | YES | | NULL | |
| avg_frequency | decimal(12,4) | YES | | NULL | |
| hist_size | tinyint(3) unsigned | YES | | NULL | |
| hist_type | enum('SINGLE_PREC_HB','DOUBLE_PREC_HB','JSON_HB') | YES | | NULL | |
| histogram | longblob | YES | | NULL | |
+---------------+---------------------------------------------------+------+-----+---------+-------+
hist_typeに「JSON_HB」というものが増えてます。
これにより、「histgram」カラムの値に、JSONとして結果を格納することができるようになります。
で、hist_typeのデフォルトは、「DOUBLE_PREC_HB」のようなので、
「JSON_HB」を使うには以下のようにするようです。
MariaDB [test]> select @@histogram_type;
+------------------+
| @@histogram_type |
+------------------+
| DOUBLE_PREC_HB |
+------------------+
1 row in set (0.001 sec)
MariaDB [test]> set histogram_type = 'JSON_HB';
Query OK, 0 rows affected (0.001 sec)
MariaDB [test]> select @@histogram_type;
+------------------+
| @@histogram_type |
+------------------+
| JSON_HB |
+------------------+
1 row in set (0.000 sec)
MariaDB [test]> analyze table user persistent for all;
：
（省略）
そうすると、mysql.column_statsのhistgramカラムにJSONが入るようになります。
長いので一部にしますが、以下のようなJSONが取得入るかと。
MariaDB [test]> select * from mysql.column_stats;
：
{
"target_histogram_size": 254,
"collected_at": "2022-06-17 23:23:19",
"collected_by": "10.8.3-MariaDB-log",
"histogram_hb": [
{
"start": "1",
"size": 0.00394246,
"ndv": 689
},
{
"start": "2047",
"size": 0.00394246,
"ndv": 689
},
：
（省略）
なにかに使えるかもしれない。。
（Spider Storage Engine Improvements）
Spider Engineは10.4でプラグイン化しました。
https://mariadb.com/kb/en/spider-installation/
で、今まではSpider用の設定がコメントであったのですが、
これを、以下の3つのシステム変数として定義できるようになったみたいです。
- REMOTE_SERVER
- REMOTE_DATABASE
- REMOTE_TABLE
従来のようにコメントでもできるようです。
これは後日試してみようかと。
（mysqlbinlog GTID support）
「–start-position」と「–stop-position」にGTIDが指定できるようになったようです。
これは嬉しい。
今まで「binlog_gtid_pos」関数使って、ファイルとポジションからGTIDを確認してましたが、
わざわざそんなことをしなくていいとなると、細かいようですが、かなりいいかなと。
ちなみに、MariaDBはGTIDを使ってレプリケーションを組むと、crash safeです。
ファイルとポジションはcrash unsafeです。
MySQLでは、
relay_log_info_repository = table
とすることで、crash safeにしていたかと。（MySQL8で、この辺もInnoDBになったはず）
という感じですかね。
Spiderとmariadb-binlog(mysql-binlog)は、後日検証しようかと思います。
また、私が作っているmagentadeskも、v0.4.5で10.8に対応しました。
https://github.com/shigenobu/magentadesk
以上