search

v-l-m / vlm

Virtual loup de mer (aka Vlm) is an opensource sailing simulation
http://v-l-m.org
GNU Affero General Public License v3.0
27 stars 10 forks source link

Migration histpos #770

Closed pzia closed 9 years ago

pzia commented 9 years ago

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

pzia commented 9 years ago

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 commented 9 years ago

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

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 commented 9 years ago

Ahem, bon, à refaire, car on touche les limites de fs :-1: 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 commented 9 years ago

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 :-1: 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 https://github.com/v-l-m/vlm/issues/770#issuecomment-76350950.

pzia commented 9 years ago

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 commented 9 years ago

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 https://github.com/v-l-m/vlm/issues/770#issuecomment-76353631.

pzia commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 :

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

fmicaux commented 9 years ago

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 https://github.com/v-l-m/vlm/issues/770#issuecomment-76586467.

pzia commented 9 years ago

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 commented 9 years ago

pourquoi ne pas faire :

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 commented 9 years ago

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 :

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 commented 9 years ago

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

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

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 commented 9 years ago

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 https://github.com/v-l-m/vlm/issues/770#issuecomment-76590707.