Migration histpos #770

pzia · 2015-02-26T06:09:19Z

Il faut decider et mettre en oeuvre la migration de histpos (beaucoup de Go).
Probablement en 2 steps :

reprise de l'historique
reprise du delta

pzia · 2015-02-26T21:21:26Z

La bonne solution semble être de désactiver le cron dbcleanup, puis de faire l'export.
Du coup, le moteur ne se bloquerai pas.
@ylafon tu confirmes ?

pzia · 2015-02-27T07:24:19Z

Bon, ok pour le test de reprise de l'historique avec

desactivation du vlmclean dans la crontab (Neptune 1)
/base/scripts/dump-history.sh (Neptune 1)
import de l'autre côté (Neptune 2)

C'est confirmé que l'export/import est trop long pour pouvoir être fait au moment de la bascule.

Une solution a "scripts constants" est de faire l'export/import 2h avant sans réactiver le vlmclean, puis de refaire le dump-alive juste au moment de la bascule.
Ca doit tenir dans la table positions pour une courte période (à vérifier)

pzia · 2015-02-27T07:37:32Z

Ahem, bon, à refaire, car on touche les limites de fs 👎
J'ai annulé l'import.

Sur neptune 1 :

/dev/mapper/vgdata-lv_mysql
42G 29G 11G 74% /var/lib/mysql
/dev/mapper/vgdata-lv_mysqllog
20G 797M 18G 5% /var/log/mysql

Sur Neptune 2 :

dev/mapper/vg00-lv_mysql 28G 1,1G 26G 5% /var/lib/mysql

@fmicaux : C'est peut être un peu juste côté fs de la db ?

fmicaux · 2015-02-27T08:04:38Z

Bonjour,

J'étais parti un peu léger, pour doser au mieux les 100 Go.

Je viens de faire ça :

lvextend -L+5G -r /dev/mapper/vg00-lv_mysql

Ca donne ça :
root@neptune2:~# df /var/lib/mysql
Sys. fich. 1K-blocks Util. Disponible Uti% Monté sur
/dev/mapper/vg00-lv_mysql 33995552 1141716 31130304 4% /var/lib/mysql

Et on peut encore compter sur 32 Go, à répartir au mieux ou garder sous
le coude :
root@neptune2:~# pvscan
PV /dev/vda5 VG vg00 lvm2 [99,76 GiB / 32,21 GiB free]
Total: 1 [99,76 GiB] / in use: 1 [99,76 GiB] / in no VG: 0 [0 ]

Par exemple, on pourrait, à la volée, et à chaud pendant l'import,
rejouer un :

lvextend -L+5G -r /dev/mapper/vg00-lv_mysql

@+
François

Le 27/02/2015 08:37, paparazzia a écrit :

Ahem, bon, à refaire, car on touche les limites de fs 👎
J'ai annulé l'import.

Sur neptune 1 :

/dev/mapper/vgdata-lv_mysql
42G 29G 11G 74% /var/lib/mysql
/dev/mapper/vgdata-lv_mysqllog
20G 797M 18G 5% /var/log/mysql

Sur Neptune 2 :

dev/mapper/vg00-lv_mysql 28G 1,1G 26G 5% /var/lib/mysql

@fmicaux https://github.com/fmicaux : C'est peut être un peu juste
côté fs de la db ?

—
Reply to this email directly or view it on GitHub
#770 (comment).

pzia · 2015-02-27T08:10:48Z

Sur Neptune 1, il y a un fs dédié pour /var/log/mysql (qui tourne avec ~1go). Sur Neptune 2, c'est direct dans /var/ => Je pense que /var est un peu léger, il faudra probablement que je l'augmente pour qu'il tienne les logs binaires de mysql Avec ce qu'on a là, je dois pouvoir faire un test d'import de histpos ce soir en désactivant les binary logs de mysql.

fmicaux · 2015-02-27T09:12:36Z

Oui, on est presque à 1 Go sur /var/log/mysql.
Il y a des historiques de mysql-slow-query + des binlog (logs pour la
réplication sur N jours)

Ca ne fera pas de mal de passer à 2 Go :

je viens de faire un "lvextend -L+1G -r /dev/mapper/vg00-lv_var" et je
préfère 63% à 96% de taux de remplissage.

Mais vu que l'on n'a plus de réplication, on peut aussi réduire le délai
de conservation de ces logs là :
Je viens de mettre (dans /etc/my.cnf) le expire-log-days à seulement 2
(jours) et au passage, j'ai passé la taille des binary logs à 10Mo, car
en condition réelle (hors import de histpos), on ne produit pas beaucoup
de modifications dans la base.

On est descendu à 40% dans /var qui reppose sur un LV de 3 Go.... je
pense que ça suffira.
J'avais (exprès) omis de séparer /var de /var/log et /var/log/mysql,
pour être un peu plus léger en conso sur ce(s) filesystems .

François

Le 27/02/2015 09:10, paparazzia a écrit :

Sur Neptune 1, il y a un fs dédié pour /var/log/mysql (qui tourne avec
~1go).
Sur Neptune 2, c'est direct dans /var/
=> Je pense que /var est un peu léger, il faudra probablement que je
l'augmente pour qu'il tienne les logs binaires de mysql

Avec ce qu'on a là, je dois pouvoir faire un test d'import de histpos ce
soir en désactivant les binary logs de mysql.

—
Reply to this email directly or view it on GitHub
#770 (comment).

pzia · 2015-02-28T21:48:14Z

Je viens de rajouter -6-, non 8go sur le /var/lib/mysql (on était arrivé au bout des 31Go...) pour voir si le chargement peut se terminer... C'est le recalcul d'index qui fait varier la volumétrie, ça devrait se stabiliser dans la nuit...

pzia · 2015-02-28T21:57:09Z

Il va falloir que je fasse quelque chose pour ces index qui nous coutent trop cher pour ce qu'ils nous servent...

CREATE TABLE histpos (
time bigint(20) DEFAULT NULL,
long double DEFAULT NULL,
lat double DEFAULT NULL,
idusers int(11) NOT NULL DEFAULT '0',
race int(11) DEFAULT NULL,
KEY race (race),
KEY idusers (idusers),
KEY idu_race_time (idusers,race,time),
KEY idu_race (idusers,race)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 |

Il y'en a au moins 2 de trop... J'ai redémarré mysql, je ferai du ménage demain

sbsrouteur · 2015-02-28T22:21:49Z

Je dirais bien 1 seul index race, idusers, time

normalement le moteur de BD devrait savoir utiliser des index partiels, donc avec 1 seul index faire la même chose qu'avec les 4 qu'on a en définition

pzia · 2015-03-01T07:32:35Z

Bon, c'est un peu compliqué de supprimer un index parce que c'est une opération longue, et qu'il n'y a pas que le cron-vlm-clean qui écrit dans histpos, mais aussi le moment ou un utilisateur passe la ligne d'arrivée. La requête est du genre INSERT INTO histpos SELECT ... FROM positions ....
Du coup ça lock la table positions et le moteur patine... (Un jour, il faudra qu'on passe sur un moteur transactionnel (InnoDb) et non fichier (myisam) )... bref...

Ce que j'ai testé en local et que je suis en train de faire en prod est :

renommer histpos en histposold RENAME TABLE histpos TO histposold ;
recréer dans la foulée la table histpos vide : CREATE TABLE histpos LIKE histposold ;
DROP INDEX race ON histposold;
DROP INDEX race ON histposold;
DROP INDEX race ON histposold;
réinsérer les enregistrements stockés dans l'interval dans histposold depuis histpos
dans la foulée, supprimer histpos, renommer histposold en histpos

J'en suis au premier index... mais comme cela duplique dans un index temporaire... on va voir...

fmicaux · 2015-03-01T07:40:55Z

Hello,

Il me semble que le passage en innodb peut se faire assez facilement,
table par table je crois.
==>Ppeut-être une piste à explorer pour histpos et positions ?

http://dev.mysql.com/doc/refman/5.6/en/converting-tables-to-innodb.html

Et réduire un peu la durée de vie des données dans histpos, ça ne règle
pas une partie du problème ?

François

Le 01/03/2015 08:32, paparazzia a écrit :

Bon, c'est un peu compliqué de supprimer un index parce que c'est une
opération longue, et qu'il n'y a pas que le cron-vlm-clean qui écrit
dans histpos, mais aussi le moment ou un utilisateur passe la ligne
d'arrivée. La requête est du genre |INSERT INTO histpos SELECT ...
FROM positions ...|.
Du coup ça lock la table positions et le moteur patine... (Un jour, il
faudra qu'on passe sur un moteur transactionnel (InnoDb) et non
fichier (myisam) )... bref...

Ce que j'ai testé en local et que je suis en train de faire en prod est :

renommer histpos en histposold |RENAME TABLE histpos TO histposold ;|

recréer dans la foulée la table histpos vide : |CREATE TABLE
histpos LIKE histposold ;|

DROP INDEX race ON histposold;

DROP INDEX race ON histposold;

DROP INDEX race ON histposold;

réinsérer les enregistrements stockés dans l'interval dans
histposold depuis histpos

dans la foulée, supprimer histpos, renommer histposold en histpos

J'en suis au premier index... mais comme cela duplique dans un index
temporaire... on va voir...

—
Reply to this email directly or view it on GitHub
#770 (comment).

pzia · 2015-03-01T07:55:12Z

Sur la suppression des index, c'est pas la bonne méthode. Je vais prévoir la procédure de dump et de bascule sans la recréation de schéma et importer dans une table vide avec juste le bon index.

Ca permettra de tester sur neptune2 une migration en innodb.

Au moment de la bascule 1->2, à J-1, on fera une opération de renommage (Cf. ci-dessous) pour ne pas perdre d'historique.

sbsrouteur · 2015-03-01T09:31:08Z

pourquoi ne pas faire :

migration n2 sans historique avec innodb et nouveaux index
dump de la table historique n1 de Neptune vu qu'il n'y aura plus d'accès on aura le temps
réimport des données en batch basse priorité sur le temps que ça prendra

Ca impose juste de faire la bascule suffisamment tot pour que l'export ai le temps de se faire. Et il n'y aura pas d'historique de traces sur n2 pendant quelques jours. Mais ça ne me semble pas bien grave.

Ou bien est ce ce qui est prévu mais j'ai pas compris?

pzia · 2015-03-01T09:40:10Z

Pour InnoDb, il faut quand même faire quel test qu'on ne fait pas actuellement pour traiter le cas des deadlock.
Dans le moteur, on a des lignes du style :

INSERT INTO histpos SELECT * FROM positions WHERE ...
DELETE FROM positions WHERE ...

Aujourd'hui, on se base sur le lock MyIsam (qui est global sur la table) pour être sur que l'insert va bien se passer... mais les deux statements sont complètement décorrélés.

Pour faire les choses biens et profiter de InnoDb en terme d'intégrité, il faudrait faire une seule transaction avec les 2 requêtes, et réessayer si InnoDb nous envoie promener.

pzia · 2015-03-01T10:14:26Z

Avec moins d'index, c'est nettement mieux (12Go d'index au lieu de 20 sur Neptune1).

@fmicaux : je t'ai rendu tes Go ;)

/dev/mapper/vg00-lv_var 2,9G 584M 2,2G 21% /var
/dev/mapper/vg00-lv_mysql 30G 22G 6,6G 77% /var/lib/mysql

L'import + recalcul d'index est long mais gérable en le faisant la veille (on récupèrera juste le delta au moment de la bascule).

Je vais écrire les procédures qui vont bien.

fmicaux · 2015-03-01T10:15:17Z

Yo,

Mais pas de problème, ces Go sont à Neptune 2 de toute façon :-P

François

Le 01/03/2015 11:14, paparazzia a écrit :

Avec moins d'index, c'est nettement mieux (12Go d'index au lieu de 20
sur Neptune1).

@fmicaux https://github.com/fmicaux : je t'ai rendu tes Go ;)

/dev/mapper/vg00-lv_var 2,9G 584M 2,2G 21% /var

/dev/mapper/vg00-lv_mysql 30G 22G 6,6G 77% /var/lib/mysql

L'import + recalcul d'index est long mais gérable en le faisant la
veille (on récupèrera juste le delta au moment de la bascule).

Je vais écrire les procédures qui vont bien.

—
Reply to this email directly or view it on GitHub
#770 (comment).

- dump only records - histpos has to be created by hand on the target server

pzia self-assigned this Feb 26, 2015

pzia added this to the Bises Arts milestone Feb 26, 2015

pzia added question C: webservices labels Feb 26, 2015

pzia modified the milestones: Bises Arts, Stick Lips Reloaded Feb 26, 2015

pzia added C: base and removed C: webservices labels Feb 27, 2015

pzia closed this as completed Mar 2, 2015

pzia added a commit that referenced this issue Mar 2, 2015

Do NOT dump histpos schema (see #770)

e2d14b0

- dump only records - histpos has to be created by hand on the target server

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Migration histpos #770

Migration histpos #770

pzia commented Feb 26, 2015

pzia commented Feb 26, 2015

pzia commented Feb 27, 2015

pzia commented Feb 27, 2015

fmicaux commented Feb 27, 2015

pzia commented Feb 27, 2015 via email

fmicaux commented Feb 27, 2015

pzia commented Feb 28, 2015

pzia commented Feb 28, 2015

sbsrouteur commented Feb 28, 2015

pzia commented Mar 1, 2015

fmicaux commented Mar 1, 2015

pzia commented Mar 1, 2015

sbsrouteur commented Mar 1, 2015

pzia commented Mar 1, 2015

pzia commented Mar 1, 2015

fmicaux commented Mar 1, 2015

Migration histpos #770

Migration histpos #770

Comments

pzia commented Feb 26, 2015

pzia commented Feb 26, 2015

pzia commented Feb 27, 2015

pzia commented Feb 27, 2015

fmicaux commented Feb 27, 2015

lvextend -L+5G -r /dev/mapper/vg00-lv_mysql

lvextend -L+5G -r /dev/mapper/vg00-lv_mysql

pzia commented Feb 27, 2015 via email

fmicaux commented Feb 27, 2015

pzia commented Feb 28, 2015

pzia commented Feb 28, 2015

sbsrouteur commented Feb 28, 2015

pzia commented Mar 1, 2015

fmicaux commented Mar 1, 2015

pzia commented Mar 1, 2015

sbsrouteur commented Mar 1, 2015

pzia commented Mar 1, 2015

pzia commented Mar 1, 2015

fmicaux commented Mar 1, 2015