Ce post est à moitié une manière de faire , et une autre une façon de mieux le faire?

Donc, vous voulez construire un système qui effectue des tâches. Vous voulez que le travail puisse être organisé en parallèle pour la vitesse, mais aussi pour la redondance. Ce système doit être coordonnée de façon, par exemple, les mêmes tâches ne sont pas faites deux fois, le statut de chaque tâche est facile à voir, et de multiples serveurs peuvent effectuer les tâches simplement en interrogeant la source centrale.

Voici la traduction de Creating a Job queue in Innodb Comment peut-on construire cela avec innodb pour avoir MySQL comme système central de notre système?

[MYSQL]
CREATE TABLE IF NOT EXISTS job_queue(
   id int(10) not null auto_increment,

   updated timestamp not null,
   started timestamp not null, …

Petite expérience sur mysql 5.1

4 tables de même structure mais 4 stockages différents : MyISAM et archive, avec et sans partition. un peu plus de 500 enregistrements ....

sans partition

MyISAM 52Ko ->Archive : 20 Ko

avec partition

Myisam 63 Ko -> Archive 12.1Ko

Là je suis étonné, l'archive avec partition est 40% plus petite.

J'ai ajouté 31000 enregistrements

sans partition

• MyISAM : 52Ko -> 1.59Mo
• Archive : 20 Ko -> 90Ko !!!!

avec partition

• MyISAM : 63 Ko -> 1.6Mo
• Archive : 12.1Ko -> 82Ko

2 grande conclusions

• L'archive ça vaut vraiment le coup quand on peut supporter ses limites
• Le partitionnement ne change rien (il y a des différences négligeables)

Je reste quand même étonné …

Pour la venue à Paris de Roch Bourbonnais, Senior Performance Analyst ZFS/OpenStorage, nous vous proposons de participer à une soirée de débats et d’échanges autour des dernières tendances du stockage de données et des meilleurs pratiques sur les performances de ZFS et de l’Open Storage. Ce sera l’occasion de réunir ensemble, à nouveau, les communautés [...]

Mysql offre la possibilité d’afficher à l’utilisateur le plan d’exécution pour une requête données. Pour cela, il suffit de précéder la requête à analyser de l’instruction EXPLAIN.

Ainsi utilisé, MySql affiche en résultat à l’utilisateur un tableau permettant de détailler comment l’optimiseur de requête va exécuter celle-ci. C’est ce qu’on appelle le plan d’exécution. Le tableau affiché en résultat peu contenir de 1 à plusieurs lignes.

Dans le cas d’une requête simple, ce tableau contiendra une ligne.

Dans le cas d’une requête contenant deux instructions SELECT associées avec la clause UNION, le tableau contiendra trois lignes :

• une ligne pour chaque exécution de l’instruction SELECT,
• une ligne pour le résultat de l’instruction UNION

Le tableau affiché contient les colonnes suivantes :

• …

Ce post est à moitié une manière de faire , et une autre une façon de mieux le faire?

Donc, vous voulez construire un système qui effectue des tâches. Vous voulez que le travail puisse être organisé en parallèle pour la vitesse, mais aussi pour la redondance. Ce système doit être coordonnée de façon, par exemple, les mêmes tâches ne sont pas faites deux fois, le statut de chaque tâche est facile à voir, et de multiples serveurs peuvent effectuer les tâches simplement en interrogeant la source centrale.

Voici la traduction de Creating a Job queue in Innodb Comment peut-on construire cela avec innodb pour avoir MySQL comme système central de notre système?

[MYSQL]
CREATE TABLE IF NOT EXISTS job_queue(
   id int(10) not null auto_increment,

   updated timestamp not null,
   started timestamp not null, …

Le but de cet article est d’optimiser une simple requête  (SELECT avg(Population) FROM city GROUP BY CountryCode) et surtout de comprendre comment l’optimiseur procède, en étudiant les résultats donnés par les variables qui permettent de surveiller le serveur MySQL.

Le schéma utilisé est le schéma world téléchargeable ici

Voici la structure de la table city:

SHOW CREATE TABLE city\G
*************************** 1. row ***************************
Table: city
Create Table: CREATE TABLE city (
ID int(11) NOT NULL AUTO_INCREMENT,
Name char(35) NOT NULL DEFAULT ”,
CountryCode char(3) NOT NULL DEFAULT ”,
District char(20) NOT NULL DEFAULT ”,
Population int(11) NOT NULL DEFAULT ‘0′,
PRIMARY KEY (ID)
) ENGINE=MyISAM …

Récemment confronté à des problèmes ponctuels d’espace disque sur un serveur gros consommateur de ce type de ressources (datawarehouse), j’ai dû temporairement jongler entre différentes partitions afin de permettre au serveur MySQL de continuer à fonctionner.

Le problème :
La partition accueillant le répertoire d’installation standard de notre MySQL arrivant à saturation, il devenait impossible de passer certaines commandes dont le ALTER TABLE. Celle-ci nécessite en effet la plupart du temps (pour MyISAM) la création de fichiers temporaires (.MYD, .MYI, .frm) dont les tailles sont semblables à celles des fichiers initiaux (aux modifications de structure près). Le hic : la taille restante sur cette partition ne permettait pas la création de tels fichiers.

Sur une table de plusieurs centaines de millions de lignes, pesant quelques dizaines de Go, un ALTER TABLE prend souvent plusieurs …

Il est pafois utile de désactiver le log binaire lors d’une restauration. MySQL permet de le désactiver pour une session avec la commande SQL_LOG_BIN:

mysql> SET SESSION sql_log_bin = 0;

Lors de la restauration avec le client mysql on peut donc utiliser la ligne de commande suivante:

shell> mysql –execute=“SET SESSION sql_log_bin=0;  SOURCE mon_fichier_dump.sql;”

La room mySql rencontre un très beau succès. Entré a l'heure juste du début de la conférence de Kris, j'ai eu une des dernières places confortables.

La présentation concernait les solutions de monitoring. Je ne vais pas m'étendre sur le contenu. Il est plus simple d'aller voir ça sur le site.

Si j'écris c'est pour dire aussi combien il est plaisant de voir la qualité de ces présentations. Mais qu'en plus les liens entre elles sont établis. Les différents orateurs connaissent les présentations des autres.

Ces 2 dernières semaines ont été bien mouvementées chez MySQL !

Sortie de la 5.1.31

Cette version est importante car elle corrige de nombreux bugs critiques de la version GA 5.1.30, qui n'était tout simplement... pas stable. Cette nouvelle version est sortie le 19 janvier mais n'est apparu sur le site que bien plus tard... Il faut mieux surveiller les mirroirs FTP. En prod sur 6 serveurs depuis fin janvier, pour l'instant aucun crash à signaler, le bug semble donc bien corrigé.

Le père de MySQL, Monty, quitte SUN

Monty quitte SUN en bon terme, et monte sa société Monty Program AB, basée sur un modèle idéaliste ou tous les employés sont actionnaire (voir le détail), et surtout, …