Discussion :

[dari68]

Bonjour,

Pour éviter le bloquage d'une table pendant une opération d'ALTER TABLE ...
J'ai pensé à utiliser l'option : ALGORITHM=INPLACE, LOCK=NONE
D'après ma lecture, cette option permet de ne pas "locker" la table par contre je me pose la question sur les risques
comme perte de données ou autres ...
un autre point, je m attendais à ce que MySQL utilise son "tempdir" mais non ce n'est pas le cas ...

Merci.

A+

[licardentaistor]

tu peux développer un peu plus, pourquoi faire un ALTER TABLE ? la structure de table ne peut pas être correct dès le début?

[dari68]

Bonjour licardentaistor,

Suite à une évolution applicative/éditeur, une mise à jour impose un drop colonnes et add colonnes avec création de nouveaux index.

Je cherche donc un moyen pour réduire au max la durée de l'indisponibilité de la base actuellement c'est plus d'une demi-journée ...

Merci.

A+

[licardentaistor]

a priori vu ta version pas de soucis: https://dev.mysql.com/doc/refman/5.6...perations.html

[Artemus24]

Salut à tous.

Pour éviter le blocage d'une table pendant une opération d'ALTER TABLE ...

Mauvaise idée !!! Et si ta bidouille se passe mal, tu fais quoi ?

Je cherche donc un moyen pour réduire au max la durée de l'indisponibilité de la base actuellement c'est plus d'une demi-journée ...

En premier lieu, on ne bidouille pas dans une base de données qui est en production.
Je suis d'accord que rendre une base de données indisponible durant une demi-journée est insupportable.

Le critère est que ta bidouille doit prendre le moins de temps, disons moins de cinq minutes.
Au delà de ce temps, c'est pas bon, car comme dit l'adage, le temps c'est de l'argent.
Comment fait-on ? Deux cas :

1) tu vas créer un script mysql qui va effectuer ta bidouille, en admettant que cela soit simple à faire.

Tu arrêtes la base de données en production.
Tu lances ton script de bidouille, en admettant que tu ne vas pas rencontrer des problèmes non prévus.
Puis tu redémarres ta base de données.
C'est une manipulation qui aura été testé (pas en production) avant de le faire car c'est très dangereux.

2) Par duplication, tu vas créer une nouvelle base de données.
J'espère que tu as installé le mode de réplication.
Tu vas devoir créer un point de sauvegarde.
Disons que ce point se fait, le matin à 10H00.

Durant ta journée, et tu prends ton temps, tu fais tes bidouilles sur ta base dupliquée.

Quand tu es prêt pour basculer, tu procèdes :
--> arrêt de la base de données en production.
--> tu bascules en production, celle sur laquelle tu viens de bidouiller.
--> tu recopies par réplication, tout ce qui a été fait depuis 10:00 du matin.
--> s'il y a encore de la bidouille à faire sur cette partie répliquer, tu dois le faire au travers d'un script mysql.
--> puis tu redémarres ta base de données.

3) ce n'est plus une bidouille, c'est une migration de données et de traitements.
Il faut le faire à des heures où tu impacteras le moins possible tes utilisateurs, soit la nuit, ou soit le weekend.

C'est ainsi que l'on travaille, en automatisant les bidouilles, et en les testant aupréalable avant de le faire en production.

Cordialement.
Artemus24.
@+

[dari68]

Merci à vous 2 de vos retour,

Je cherchais un équivalent à l'option "ONLINE" d'Oracle et SQL Server qui permet de créer un index par exemple sans bloquer les accès à la table ...

A+

[Artemus24]

Salut à tous.

Suite à une évolution applicative/éditeur, une mise à jour impose un drop colonnes et add colonnes avec création de nouveaux index.

Cela ne prend pas une demi-journée pour faire cela.
Créer un index se fait en désactivant les contrôles puis en les rétablissant après :

Code mysql :

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

1
2
SET UNIQUE_CHECKS=0;
ALTER TABLE `nom_de_la_table` DISABLE KEYS;

Puis après avoir créé vos index, vous faites :

Code mysql :

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

1
2
3
ALTER TABLE `nom_de_la_table` order by id;
ALTER TABLE `nom_de_la_table` ENABLE KEYS;
SET UNIQUE_CHECKS=1;

Ce sont les contrôles qui prennent du temps, pas la création en elle-même.
Maintenant, j'espère que vous n'allez pas créer un "unique index" sur une colonne qui contient des doublons.

Pour éviter le blocage d'une table pendant une opération d'ALTER TABLE ...
J'ai pensé à utiliser l'option : ALGORITHM=INPLACE, LOCK=NONE

Vous n'aurez pas de blockage mais carrément un plantage si l'un de vos traitements vient à interroger la table qui ne contient plus la colonne que vous venez de supprimer.
Cette astuce fonctionne que si vous ne modifiez pas la structure de votre table.

Cordialement.
Artemus24.
@+

[SQLpro]

Merci à vous 2 de vos retour,

Je cherchais un équivalent à l'option "ONLINE" d'Oracle et SQL Server qui permet de créer un index par exemple sans bloquer les accès à la table ...

A+

Tu penses sérieusement qu'un outil gratuit hyper bugué est capable de faire ce que fais Oracle ou SQL Server ???*

A +

[dari68]

Hello,

Artemus24, Merci de ces précieuses infos

J'ai fait un tests pour la création des UNIQUE INDEX avec la désactivation de la containte unicité:

Code :

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

1
2
3
4
5
6
7
mysql> SET UNIQUE_CHECKS=0;
Query OK, 0 rows affected (0.00 sec)
CREATE UNIQUE INDEX .....
CREATE UNIQUE INDEX .....
CREATE UNIQUE INDEX .....
mysql> ALTER TABLE STSTAK  DISABLE KEYS;
Query OK, 0 rows affected, 1 warning (0.00 sec)

Je ne comprends pas , les temps d'exécutions sont multipliés par 2 !!!

et pour

Code :

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

ALTER TABLE xxxxx ,ALGORITHM=INPLACE, LOCK=NONE

J'ai lancé une série d'insert en // de ALter table add column ...et la table et la table reste verouillée:

Code :

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

Waiting for table metadata lock

@SQLPro, je découvre MySQL mais SQL Server commence à me manquer

A+