Discussion :

[FreelanceDBA]

Un bon point pour vous SQLPro.
Etant donné que vous êtes un expert de SQL Server, y a-t-il des jurisprudences concernant des clients s'étant retournés contre Microsoft pour des problèmes avec SQL Server et ayant eu gain de cause ? (si oui, de quels montants ?)

Tant que je vous tiens sous les yeux, qui a raison sur cette histoire de clés étrangères violées et de sauvegarde à chaud ?
Parce que pour moi rien n'est clair...

Pour les clefs étrangères je n'ai pas eu le temps de faire les test ad hoc. Pour les backup à chaud je suis affirmatif : utilisez innodb et Mariabackup ça marche très bien.

[FreelanceDBA]

support payant que tu peux avoir aussi hors du libre.

Bien sur. En sus du droit d'octroi pour avoir simplement le droit de l'utiliser. C'est vrai.

[webMCA]

Le seul moyen d'approcher une sauvegarde non bloquante est d'avoir un réplica… Autrement dit pour une simple sauvegarde je suis obligé de monter une usine à gaz ! Finalement le libre ça coute cher !

Donc, je maintient et j'affirme que MySQL ne sait pas faire des sauvegardes consistante sans blocage...

A +

Donc j'insiste lourdement sur le fait que xtrabackuo et Mariabackup réalisent bel et bien des backups physiques consistants, à chauds et sans blocage quand on daigne utiliser le moteur de stockage innodb.
Après il est toujours possible de trouver des cas où les utilisateurs font tellement n'importe quoi que c'est impossible à sauvegarder je ne le nierais pas. Toutefois avec un minimum de best practice (la premiere étant pourquoi diable foutre autre chose qu'un produit Microsoft sur un serveur windows) il 'y a pas de souci.

Du coup je suis toute ouïe sur la demonstration théorique de pourquoi il est impossible de faire un backup consistent et non bloquant.

J'adore. ça ça fait avancer le débat.
Chacun maintient son point de vue et affirme.
On attend la (vraie) démonstration.

[FreelanceDBA]

J'attends surtout la démonstration comme quoi il est impossible que ça marche.
Je constate toutes les semaines que des backups consistants sont pris à chauds sans lock et I impacts majeurs sur les performances grâce à xtrababackup ou mariadb.

J'attends donc de savoir comment un tel miracle peux se produire quotidiennement autour du globe alors que c'est censé ne pas fonctionner. Pour l'instant le seul cas documenté est à côté de la plaque.

[François DORIN]

J'attends surtout la démonstration comme quoi il est impossible que ça marche.

Des problèmes de consistances et des problèmes de locks (cf. footnote 1).

L'éditeur même de la solution le dit. Il te faut quoi de plus ?

SQLPro donne un cas d'expérience pour lequel cela ne fonctionne pas. Mais non, c'est une mauvaise utilisation car "à coté de la plaque".

Maintenant, ça ne veut pas dire que les backup ne fonctionnent pas correctement de manière générale, mais qu'il peut y avoir des cas où, tu penses avoir backuper, et tu as des données corrompues. Tu penses faire un backup sans lock, mais tu te retrouves quand même à avoir un lock de quelques secondes. Pour un site web (majeur partie de l'utilisation de MySQL/MariaDB), ce n'est rien, un "désagrément" pour l'utilisateur qui se remarquera à peine voir pas du tout, mais cela ne signifie pas qu'il n'existe pas.

Pour les clefs étrangères je n'ai pas eu le temps de faire les test ad hoc

Je t'invite fortement à le faire. Tu pourras ainsi constater par toi-même.

[FreelanceDBA]

L'éditeur indique qu'il y a des problemes de verrouillage quand on backup des tables utilisant un moteur autre qu'innodb en effet. Ce qui n'est pas étonnant car xtrabackup à été créé au départ pour backup innodb.

De la a affirmer que mariadb ne sait pas faire de backup consistant non bloquant c'est un peu fort. Dans certaines conditions ce n'est pas possible est la seule affirmation juste en la matière.

[François DORIN]

L'éditeur indique qu'il y a des problemes de verrouillage quand on backup des tables utilisant un moteur autre qu'innodb en effet.

Non. cela signifie que le backup des tables InnoDB est non-bloquant, mais que le backup des logs bloque ces tables.

[sergio_is_back]

Bingo, c'est le cas


Windows 10, et MariaDB (pas MySQL) avec WAMP. Maintenant, je concède que ce n'est pas une prod. J'ai juste fait l'installation aujourd'hui sur mon poste pour revérifier (je ne vais pas "polluer" un truc en prod juste pour un petit test ).

Je veux bien croire que Windows 10 + NTFS ne soit pas la norme pour MariaDB (et j'avoue qu'il ne me viendrait même pas à l'idée de faire une installation ainsi, sauf si c'était sur un serveur déjà existant), mais si le moteur InnoDB ne fonctionne pas de la même manière sur un truc aussi gros que les contraintes de clé étrangères en fonction du système de fichiers, c'est un énorme souci de conception !

Si tu veux faire un test correct, installe directemennt MariaDB 10.x sur ton poste de travail. WAMP installe MariaDB avec son propre fichier my.ini dans lequel il y a souvent des réglages qui sont indésirables en prod, faut pas oublier que c'est conçu pour développer rapidement un petit site WEB en Php sans trop se poser de questions, perso j'utilise jamais ça... Ensuite utilise HeidiSQL (livré avec MariaDB) comme client pour tester...

[DarkCenobyte]

Si tu veux faire un test correct, installe directemennt MariaDB 10.x sur ton poste de travail. WAMP installe MariaDB avec son propre fichier my.ini dans lequel il y a souvent des réglages qui sont indésirables en prod, faut pas oublier que c'est conçu pour développer rapidement un petit site WEB en Php sans trop se poser de questions, perso j'utilise jamais ça... Ensuite utilise HeidiSQL (livré avec MariaDB) comme client pour tester...

Ou pour éviter des conflits entre les deux, peut-être qu'une petite VM sous VirtualBox avec une Debian très légère serait plus simple et réaliste (sauf peut-être niveau performance IO...)

[FreelanceDBA]

Non. cela signifie que le backup des tables InnoDB est non-bloquant, mais que le backup des logs bloque ces tables.

Le but de citer un article est de le lire jusqu'à la fin. L'option no lock vous évite ce global lock à la fin sans rendre le backup inconsistant pour autant. Ce qui est pus amène donc à : un backup à chaud consistant non bloquant.

[François DORIN]

Le but de citer un article est de le lire jusqu'à la fin...

..et de comprendre ce que cela signifie. Pour être efficace, il est nécessaire d'avoir un serveur compatible. Or, seul Percona Server implémente la fonctionalité indispensable pour cela, ce qui n'est pas le cas de MariaDB qui déconseille fortement son utilisation.

[SQLpro]

...Là ou ça devient plus compliqué et litigieux, c'est sur les effets indirects d'un bug du produit comme une corruption de données, ou un effet de bord sur une partie du SI autre que la base pour notre exemple. ...

Deux cas sont à distinguer :

• l'utilisation directe, alors c'est de la responsabilité de l'exploitant. Par exemple l'entreprise qui a choisit le libre pour développer une application "maison".
• L'éditeur de logiciel. Vu qu'il vend, c'est de sa responsabilité, car il a imposé une solution dont il a l'intégralité de la responsabilité.

Dans le cas du monde commercial, l'éditeur peut se retourner contre le fabricant du SGBDR….

A +

[chrtophe]

Non. cela signifie que le backup des tables InnoDB est non-bloquant, mais que le backup des logs bloque ces tables.

Pour moi c'est pas très clair.

En regardant la doc :https://www.percona.com/doc/percona-...read-lock.html

Cela rejoint ce qui a été expliqué, blocage de tables. Des option permettent de pallier cela. Mais je ne sais pas les conséquences. Percona peut même killer les requêtes trop longues pour mettre son verrou, un peu violent (mais c'est une option éventuellement envisageable pour un SELECT tant qu'on gère en amont). On peut tout a fait comprendre qu'avec un usage intensif sur une base, il peut être difficile de poser un verrou quand il n' a aucune requête active. Et autre problème aussi, le délai de pose de ce verrou. Mais d'un autre coté, la pose de verrou lui-même doit se faire en micro-secondes.

[Willy_k]

Sur deux tables, dans deux schémas différents, avec une clé étrangère entre les deux ?
Car sur deux tables du même schéma, je n'ai effectivement aucun souci.

Pas possible de référencer la colonne d'une table d'une base de données(schéma) autre que celle actuelle ou j'ai pas compris la question.

[François DORIN]

Pas possible de référencer la colonne d'une table d'une base de données(schéma) autre que celle actuelle ou j'ai pas compris la question.

Bien sur que si c'est possible ! SQL Pro donne d'ailleurs le code pour y arriver dans son article

[Willy_k]

"ALTER TABLE" me disait le contraire.
Et j'ai testé le code de SQLPro, pas vraiment de clé étrangère créée , ce qui est signifié dans la doc https://mariadb.com/kb/en/library/foreign-keys/

[François DORIN]

Et j'ai testé le code de SQLPro, pas vraiment de clé étrangère créée , ce qui est signifié dans la doc https://mariadb.com/kb/en/library/foreign-keys/

C'est très étonnant ce choix de la part de MariaDB, d'accepter une syntaxe mais de ne rien faire derrière (alors que la fonctionnalité est implémentée via une autre syntaxe).

Voici le script que j'ai utilisé pour faire un test :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE SCHEMA s1;
CREATE SCHEMA s2;
 
CREATE TABLE s1.t1
(
	id INT AUTO_INCREMENT,
    CONSTRAINT pk PRIMARY KEY(id)
) ENGINE= InnoDB;
 
CREATE TABLE s2.t2
(
	id INT NOT NULL,
    ref INT NOT NULL,
    CONSTRAINT fk2 FOREIGN KEY(ref) REFERENCES s1.t1(id)
) ENGINE= InnoDB;
 
INSERT INTO s2.t2(id, ref) VALUES (1, 1);

J'ai testé sur MySQL (v5.7.26) et MariaDB (10.3.14).

MySQL ne bronche aucunement et permet l'insertion d'une ligne en violation complète de la clé étrangère.
MariaDB gueule (comportement attendu d'un SGBD).

Donc, le coup de la clé étrangère n'est a priori valable que pour MySQL, et non pour MariaDB.

[Willy_k]

MYSQL 5.7.11 et MariaDB j'ai ça

Erreur dans la requête (1452): Cannot add or update a child row: a foreign key constraint fails (`s2`.`t2`, CONSTRAINT `fk2` FOREIGN KEY (`ref`) REFERENCES `s1`.`t1` (`id`))

[chrtophe]

J'ai testé sur MySQL (v5.7.26)

François, l faudrait peut-être tester avec la version 8.

[François DORIN]

François, l faudrait peut-être tester avec la version 8.

Effectivement, avec la version 8, j'ai une erreur. Certaines choses ont semble-t-il été corrigées.

Est-ce que cela change ma position sur MySQL/MariaDB ? Pas vraiment. Car je trouve que cela est quand même révélateur d'un gros problème : la prise en compte des contraintes de clé étrangères dépend de la syntaxe utilisée. La déclaration au niveau d'une colonne est ignorée, et seule la déclaration au niveau de la table est prise en compte. C'est quand même un gros manquement, surtout que les deux déclarations syntaxes font parti de la norme pour une fonctionnalité aussi essentielle.

Le pire dans tout ça, c'est que la syntaxe de déclaration au niveau de la colonne est supportée mais est sans effet. A ce titre, il vaudrait mieux que cela génère une erreur afin que l'utilisateur sache que sa requête n'a pas l'effet escompté et que la contrainte n'est pas créée.

Qui me dit qu'il n'y a pas d'autres aspects "de base" qui sont partiellement implémentées syntaxiquement parlant ?