Mariadb : Connect Engine

Le "vieux" plugin "federated" n'est plus maintenu, il existe une autre version "federatedx" qui fonctionne correctement sur Mysql (détails ici), je ne l'ai pas testée récemment sur MariaDB.
La méthode "IN" préconisée aujourd'hui pour MariaDB est d'utiliser le plugin "CONNECT". Celui-ci met à votre disposition un nouvel "ENGINE" qui permet la connexion à des bases distantes (de diverses saveurs), à des fichiers "plats", du Xml, du Json.
Le "CONNECT ENGINE" fait parfois partie des distributions stantard sur Linux :
- Debian/Ubuntu : apt install mariadb-plugin-connect
- RedHat/Centos/Fedora : yum install MariaDB-connect-engine
Ensuite il suffit de l'activer (avec un utilisateur qui a des droits suffisants !) :

mysql --user=... -p
prompt> INSTALL SONAME 'ha_connect';
prompt> \q

Ensuite on pourra passer aux choses sérieuses ...
La création des tables reste classique, quelques exceptions notables :

Pas de champ en AUTO_INCREMENT --> utiliser des séquences gérées "à la main" (MariaDB >= 10.3).
Un champ présent dans un index doit absolument être spécifié "NOT NULL".
Pas de champs TEXT/BLOB, ça c'est un peu dommage !
Les clefs d'index ne doivent pas dépasser 255 caractères.

En ce qui concerne l'accès à une base Mysql/MariaDB le protocole étant standardisé il suffit d'indiquer après les définitions d'index :

... définition des données et index ...
) Engine=CONNECT DEFAULT CHARSET xxxxxx
table_type=mysql
connection='mysql://USER/PASSWORD@HOST/DATABASE/TABLE';

La table est crée et permet un accès direct aux données. On peut, bien sûr, utiliser un mélange de tables locales et distantes dans le même ordre SQL.
Je m'en suis notamment servi pour repérer des différences au sein d'un cluster maître/maître qui avait subi quelques manipulations hasardeuses au niveau de la définition des GTID des slaves (mélange entre gtid_slave_pos et gtid_current_pos).
Quelques tests rapides.
Les tests ont été réalisés sur deux VM identiques Debian 10 sur KVM :
2 vcpu, 2Go de RAM, une seule partition disque de 127Go sur une carte M2, MariaDB 10.3.23 paramétré avec un cache InnoDB de 1Go et 4 pool instances.
Chaque machine dispose de deux tables locales quasiment identiques, les tables notées "Z_..." sont des tables distantes, celles notées "D_..." sont des tables locales. L'espace disque est d'environ 1,7Go par table.

Mysql redémarré avant le premier test (caches vidés) :
Un test rapide de comptage sur table distante.

select count(*) from Z2_TABLE_DISTANTE
+----------+
| count(*) |
+----------+
| 1454065 |
+----------+
1 row in set (0.984 sec)

select count(*) from Z2_TABLE_DISTANTE;
+----------+
| count(*) |
+----------+
| 1454065 |
+----------+
1 row in set (0.910 sec)

L'effet du cache n'est ici pas énorme, même pas 10% de gain.
Test sur la même table en local :

select count(*) from D2_TABLE_LOCALE
+----------+
| count(*) |
+----------+
| 1454065 |
+----------+
1 row in set (0.379 sec)

select count(*) from D2_TABLE_LOCALE;
+----------+
| count(*) |
+----------+
| 1454065 |
+----------+
1 row in set (0.229 sec)

L'effet du cache est ici beaucoup plus notable ...

Autre test : jointures entre table distante et table locale :

select count(*)
from Z1_TABLE_DISTANTE Z1
join D2_TABLE_LOCALE D2 on D2.ID = Z1.ID;
+----------+
| count(*) |
+----------+
| 1454065 |
+----------+
1 row in set (6.093 sec)

select count(*)
from D1_TABLE_LOCALE Z1
join D2_TABLE_LOCALE D2 on D2.ID = Z1.ID
+----------+
| count(*) |
+----------+
| 1454065 |
+----------+
1 row in set (4.349 sec)

Les performances sont ici très correctes la différence de temps d'exécution est relativement faible ce moteur est très facile à utiliser et présente des performances intéressantes.

Autre test :
Voir la différence entre le traitement d'une table "locale" et d'une table "pseudo distante" (déclarée comme une table distante mais utilisant l'adresse de la machine locale) :

select count(*) from Z2_TABLE_PSEUDO_DISTANTE;
+----------+
| count(*) |
+----------+
| 23919958 |
+----------+
1 row in set (11.853 sec)

select count(*) from TABLE_LOCALE;
+----------+

| count(*) |
+----------+
| 23919958 |
+----------+
1 row in set (3.613 sec)

La différence est assez significative, j'ai refait plusieurs essais pour éliminer l'influence du cache mais la table utilise environ 13 Go d'espace disque, le cache de 1Go ne joue que peu.

Version imprimable