2023年2月にMariaDB 10.11がリリースされました。

https://mariadb.com/kb/en/changes-improvements-in-mariadb-1011/

LTSリリースということで、2028年2月までのサポートとなります。

基本的には、リリースノートを見ていただければとは思いますが、

個人的には system versioning テーブルの dump/restore サポートがついに入ったか〜という感じです。

たとえば、こんな感じで、テーブルつくって、データ操作します。

create table t_system_versioning (
  id int not null,
  name varchar(32) not null,
  primary key (id)
) with system versioning;

insert into t_system_versioning values (1, 'n1');
update t_system_versioning set name = 'n2' where id = 1;
delete from t_system_versioning where id = 1;

このあとの段階では、当然以下のようになります。

MariaDB [test]> select * from t_system_versioning;
Empty set (0.000 sec)

履歴をすべてを出力すると、以下のようになります。

MariaDB [test]> select *, row_start, row_end from t_system_versioning for system_time all;
+----+------+----------------------------+----------------------------+
| id | name | row_start                  | row_end                    |
+----+------+----------------------------+----------------------------+
|  1 | n1   | 2023-03-22 16:56:29.376669 | 2023-03-22 16:56:53.845864 |
|  1 | n2   | 2023-03-22 16:56:53.845864 | 2023-03-22 16:57:08.520850 |
+----+------+----------------------------+----------------------------+
2 rows in set (0.000 sec)

これまでは、これらの履歴データが dump で取得できませんでした。

10.11で追加されたオプション「–dump-history」を使うことで、履歴が dump に載るようになります。

$ mariadb-dump --databases test --tables t_system_versioning --dump-history
:
:
/*!101100 SET @old_system_versioning_insert_history=@@session.system_versioning_insert_history, @@session.system_versioning_insert_history=1 */;
LOCK TABLES `t_system_versioning` WRITE;
/*!40000 ALTER TABLE `t_system_versioning` DISABLE KEYS */;
INSERT INTO `t_system_versioning` (`id`, `name`, row_start, row_end) VALUES (1,'n1','2023-03-22 07:56:29.376669','2023-03-22 07:56:53.845864'),
(1,'n2','2023-03-22 07:56:53.845864','2023-03-22 07:57:08.520850');
/*!40000 ALTER TABLE `t_system_versioning` ENABLE KEYS */;
UNLOCK TABLES;
:
:

これで、やっと system versioning も使い易くなった感じです。

デフォルトの挙動としてもいい気がしますが。。

その他として、GPGキーが2023年から変わっています。

https://mariadb.com/kb/en/gpg/

バージョンアップの際は、上記を参考にGPGキーを更新する必要があるので、注意が必要です。

また、自分が作成している magentadesk も10.11 に対応しました。

https://github.com/shigenobu/magentadesk

v0.4.9 が 10.11 の対応版となります。

以上

投稿日時:2023年03月22日 17:10   カテゴリー:java, mariadb  

ER master という優れたツールがあります。

https://ermaster.sourceforge.net/index_ja.html

ただ、もう10年前に更新が止まっており、

eclipseプラグインの上、新しいeclipseでは動作しない(?)ものとなっています。

ER master は、データベースの管理はもとより、設計に注力したツールかと認識しており、

未だこれ以上のものは市場にはないような気はしています。

※有償でしか触れないようなものは除く

ずっと、ER master の代替になるようなものを作りたいと思っており、

非常に不十分ではありますが、ちょっとつくってみました。

(ebonyrack)

https://github.com/shigenobu/ebonyrack

https://github.com/shigenobu/ebonyrack/releases/tag/v0.0.1

mariadbの特有機能を盛り込もうかと思ってmariadbと書いてありますが、

特有機能を入れすぎて、複雑になりすぎてしまったため、

結局特有機能は削ぎ落とし、結果としてmysqlでも問題はない形になっています。

現時点では、不具合もあるでしょうし、機能不十分ではありますが、非常に大変でした。

クロスプラットフォーム(WIN、MAC、LINUX)での動作を目標としたため、

JAVAのSWINGで作成してします。

SWINGは基本機能は揃っていますが、

いわゆる気の利いたコンポーネントはないため、かなりコード量が肥大化しました。

よかったら使ってみてください。

今後もバージョンアップは続けますので。

以上

投稿日時:2023年03月22日 14:51   カテゴリー:java, mariadb, mysql  

C#で、IPアドレスを取得する際、Dns.GetHostEntryを使うという記事がよく出てきます。

当然、DNSサーバを利用する前提なので、DNSサーバから正引きできないと、

結局は、ローカルループバックアドレスしか取れなかったりします。

ローカルネットワークであっても、

consulやdnsmasqなどをつかって、DNS設定くらいちゃんとしとけよというのはもちろんですが、

IPアドレスだけで済むなら、そうしたいのものかと思います。(WINSサーバについては不明です)

このように、正引きできないが、ローカルアドレスを取りたい場合、

NICを直接見に行くほうが楽です。

自分のTCPサーバ・クライアントライブラリに、将来的に使いそうな気がして、実装しておきました。

https://github.com/shigenobu/PurpleSofa/blob/master/PurpleSofa/PsNetwork.cs

v4のアドレス取得部分だけ抜粋します。

    private static readonly IEnumerable<NetworkInterface> NetworkInterfaces = NetworkInterface.GetAllNetworkInterfaces()
        .Where(i =>
            i.OperationalStatus == OperationalStatus.Up &&
            i.NetworkInterfaceType == NetworkInterfaceType.Ethernet &&
            i.NetworkInterfaceType != NetworkInterfaceType.Loopback);

    public static IEnumerable<IPAddress> GetLocalIpv4Addresses()
    {
        List<IPAddress> addresses = new();
        foreach (var networkInterface in NetworkInterfaces)
        {
            var address = networkInterface.GetIPProperties().UnicastAddresses
                .Where(a => a.Address.AddressFamily == AddressFamily.InterNetwork)
                .Select(a => a.Address)
                .FirstOrDefault();
            if (address != null)
                addresses.Add(address);
        }

        return addresses;
    }

要は、起動中のイーサネットのNICだけを取得して、それをIEnumerableで返している感じです。

これでWIFIも取れるかと思います。(LINUXでは大丈夫だったが)

NICを複数持っているケース、

たとえばゲートウェイサーバのように、外向きと内向きのアドレスを持つ場合などについては、

https://learn.microsoft.com/ja-jp/dotnet/api/microsoft.aspnetcore.httpoverrides.ipnetwork?view=aspnetcore-7.0

なんていうクラス(ASPですが)を使うことで、

取得したアドレスが、指定のアドレス範囲内かどうかを判断して、取捨選択も出来るかと思います。

以上

投稿日時:2023年01月12日 23:27   カテゴリー:c#  

私が作成しているPurpleSofaの0.0.9で、IPv6対応をしました。

https://www.nuget.org/packages/PurpleSofa/

v6のサーバというのは、初めて作ったのですが、

フォーマットや省略ルールなど、以下のIBMのサイトがよくまとめられていたので、記載します。

https://www.ibm.com/docs/ja/i/7.1?topic=6-ipv6-concepts

C#の実装におけるポイントですが、

  • v4の「0.0.0.0」(anywhere)は、v6では「::」に相当
  • ソケットオプションで、v6でlistenする場合は、v6onlyをfalseにしておくとv4のソケットをv6として扱ってくれる

ぐらいでした。

(v6でlistenしても、v4を扱う設定)

_socket.SetSocketOption(SocketOptionLevel.IPv6, SocketOptionName.IPv6Only, false);

クラウドなんかでは、フロントとなるCDNとかロードバランサが、v6→v4変換とかもしれくれるので、

あんまりv6を直接扱う需要性は低いような気はしますが、

海外では、v6アドレスしか提供しないプロバイダなんかもあるようで、

ある程度v6の対応というか準備もしておいたほうがいいのかなと思うこの頃です。

以上

投稿日時:2023年01月12日 22:59   カテゴリー:c#  

mysqlやmariadbからData Ware House(以下、DWH)へレプリケーションしたいな、って最近思います。

実際のところ、DWHがupdate/deleteといった行操作に弱いので、

なかなかDWHが使えない状況が続いていますが、

最近ではTiDBのTiFlushや、OCIのheatwaveといったもの(行操作も強そうなもの)が出てきているので、

OLTPのmysql/mariadbから、シームレスにレプリケーションいけそうじゃないか?

という感触を持っています。

とはいえ、update/delete問題が解決しても、実際はOLTPのデータベースと、

DWHをつなぐときは、マルチソースレプリケーションである必要があったり、

そもそも各種DDLを解決したりと、なかなか簡単には事が運ばない印象です。

そんなこんなで、Change Data Capture(以下、CDC)が使えるんじゃないかな?

とずっと思っていたのですが、C#にCDCのライブラリがあったので、紹介しておきます。

https://github.com/rusuly/MySqlCdc

まだ、動作検証はしてないですが、かなり色々できそうな気がしてます。

CDCのソフトウェアは有償・無償と色々ありますが、

実際にSQL(イベント)をアプリケーションで捕まえることができるようになるので、

ある程度mysqlのレプリケーションをしっているエンジニアであれば、

かなり面白いことができそうな気はしてます。

以上

投稿日時:2022年11月29日 17:22   カテゴリー:c#, mariadb, mysql  

2022年8月にMariaDB10.9が、

2022年12月にMariaDB10.10がリリースされました。

10.9も10.10もShort Term Supportということで、

サポートは最初のGAリリースから1年のようです。

10.6が直近のLTS(サポートは2026年6月まで)なのですが、

どうやら、次の10.11がLTSになるようです。

https://mariadb.org/mariadb-10-11-is-lts/

10.9と10.10の変更点については、リリースノートを参照ください。

なかなか内容の把握が難しい。。

(10.9)

https://mariadb.com/kb/en/changes-improvements-in-mariadb-109/

(10.10)

https://mariadb.com/kb/en/changes-improvements-in-mariadb-1010/

一応、自分の作っているmagentadeskも10.10に合わせて対応済みです。

10.10でinet4型が入ったので、まあそのくらいですが。

https://github.com/shigenobu/magentadesk

以上

投稿日時:2022年11月29日 17:06   カテゴリー:mariadb  

mysqlプロトコル対応のwriteスケールアウトのDBについて書いてみる。

最初に言っておく、全部触ったことがない!


(MySQL NDB Cluster)

https://dev.mysql.com/doc/refman/8.0/ja/mysql-cluster.html

ライセンスは、GPLと商用の2種類あるよう。商用はサポートあり。

アーキテクチャは、管理ノード・SQLノード・データノードに分かれるもので、いわゆるshared nothing型。

トランザクション分離レベルは、READ COMMITTEDのみサポート。

(MariaDB Xpand)

https://mariadb.com/ja/products/enterprise/xpand/

ライセンスは商用のみ。

各ノードが管理・SQL・データを兼任し、いわゆるshared nothing型。

トランザクション分離レベルは、REPEATABLE READとREAD COMMIETTEDをサポート(一応SERIALIZEDもOKみたい)。

(TiDB)

https://pingcap.co.jp/tidb-overview/

ライセンスはApache2.0。

アーキテクチャは、管理ノード・SQLノード・データノードに分かれるもので、いわゆるshared nothing型。

v3.0からMySQLに近い「PESSIMISTIC TRANSACTION」をサポートし、v4以降は、READ COMMITTEDのみサポート。

(Vitess)

https://vitess.io/

ライセンスはApache2.0。

kubernatesでの動作が前提(一応、他でも動くみたい)。

データノードは、通常のmysqlなので、InnoDBが利用可能。

多分、トランザクション分離レベルは、READ COMMITTEDをサポート。(よくわからん)


分散DBは、正直使ってみて、

挙動を確かめてみないとわからない。。

よくあるのが、

  • SQLの構文がサポートされていなかった
  • データタイプがサポートされていなかった
  • トランザクションがCOMMIT勝負だった
  • ロックの挙動がmysqlと違う
  • JOINが結構遅い
  • 集約の結果がちょっとずれてる

などがあるのかな〜。

その他には、

  • 障害時の復旧手順(復旧順番間違えるとロスト)
  • バックアップ時の負荷

など、開発だけでなく、運用時のシュミレーションと検証を結構しておく必要があるかなと。

最近は、DaaS(Database as service)も結構あるので、運用は任せてしまうのも一手かもしれないが。

いずれにせよ、「銀の弾丸」はないわけで、

インフラのエンジニアも、アプリケーションのエンジニアも、

よく検証して、できること・できないこと、どうやったらまずいのかなど、

を整理しておく必要があるのかなと。

以上

投稿日時:2022年06月21日 23:23   カテゴリー:mariadb, mysql  

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

以上

投稿日時:2022年06月17日 23:52   カテゴリー:mariadb  

アプリケーションで長々SQLを書かなきゃいけないんだけど、

条件によってはSQLを評価しないときってあるかと思います。

たとえば、検索するときの対象テーブルとして、

  • 記事
  • 動画

の2つがあったとき、条件によっては、記事のみにしたいって場合です。

このとき、アプリケーションのIFで、動画のSQLは流さないようにするってのが普通だと思うんですが、

CTE(WITH)とか使っていると、後続の式(たとえばUNION)で動画の分を抜くとか調整しなくちゃいけなくてめんどくさかったり。。

そんなとき、ちょっと役に立つ技が「LIMIT 0」です。

これは、公式にも書いてあるように、即座に空の結果セットを返すというものです。

https://dev.mysql.com/doc/refman/8.0/ja/limit-optimization.html

explain時のExtraには、「Zero limit」というのが表示されます。

それ以外にも、SQLとして正しいかどうかだけをチェックするときにも使えたりします。

「LIMIT 0」以外にも、自分の小ネタを紹介しておきます。

たとえば、アプリケーションでWHEREを組み立てなきゃいけないとき、

条件がなにもなかったら、WHERE句自体を消すとかもありますよね。

そんなとき、自分は「1 = 1」で初期化しておくみたいなこともやったりします。

そうすると、WHERE句自体は残したままでよくなるので、文字列編集の煩わしさが減ります。

「LIMIT 0」とか「WHERE 1 = 1」とか、はっきいって邪道ですが、

使うと意外にアプリケーションでのSQL構築が楽になったりします。

以上

投稿日時:2022年05月10日 00:07   カテゴリー:mariadb, mysql  

ubuntu22.04LTSがリリースされ、

私が使っているpoposも追従して22.04が発表されたので、

アップデートしてみました。

(popos)

https://pop.system76.com/

しかし、必ず悲劇はあるもので、今の所直面した悲劇を2つご紹介します。

①VPNがつながらない

私が努めている会社では、

  • YAMAHAルータのVPN(IPsec)
  • LINUXサーバのVPN(xl2tpd+IPsec)
  • OpenVPN

の3つを用意しているのですが、22.04へのアップデート直後は、

OpenVPN以外は接続できないという状態となりました。(poposがVPNクライアントです)

IPsecがつながらない原因を調査していくと、どうやら ubuntuのバグにも多数報告が上がっていました。

https://bugs.launchpad.net/ubuntu/+source/xl2tpd/+bug/1951832

ずっとたどっていくと、

「xl2tpd – 1.3.16-1ubuntu0.1」というバージョンが急遽リリースされたようで、

これをインストールすることで、

  • LINUXサーバのVPN(xl2tpd+IPsec)

はなんとかつながるようになりました。

しかし、YAMAHAルータの方は、接続はできても、その後以下のようなエラーが発生し、切断されてしまいます。※経路の確立ができていない感じですかね。

xl2tpd[10265]: check_control: Received out of order control packet on tunnel 37328 (got 2, expected 3)
xl2tpd[10265]: handle_control: bad control packet!

これについては、ちょっとわかならい。。認証か暗号化の段階なのか。。

SSHがつながらない

というかつながるHOSTとつながらないHOSTが発生した。

つながらないHOSTをよくみたら、

sign_and_send_pubkey: no mutual signature supported

というエラーが発生していた。

これは、

20.04のときのOpenSSHクライアントが8.2で、

22.04になったらOpenSSHクライアント8.9になっており、

間の8.3リリースで、「ssh-rsa」が禁止されているためであった。

とりあえず、~/.ssh/configに以下の記載を追加して対応。

Host *
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedKeyTypes +ssh-rsa

途中の非LTSを飛ばしたので、なかなか大変。。

というわけで、アップデートは計画的に。

以上

投稿日時:2022年05月09日 23:30   カテゴリー:popos, ubuntu