News MYSQL

Ecrire un commentaire
Il existe désormais une commande LOAD XML, qui analyse un fichier XML pour le charger en base de données. Elle fonctionne sur le même principe que LOAD DATA, mais analyse partiellement le code XML pour deviner les lignes et les colonnes. Le tout est reconstitué dans une table MySQL.

Disponible depuis MySQL 5.2.5, c'est à dire 6.0.0. A l'inverse, le client MySQL est déjà capable de produire des résultats en XML depuis longtemps. C'est l'option --xml ou -X.

- Follow up on LOAD XML
- LOAD XML documentation
- LOAD XML contribution added to MySQL
Ecrire un commentaire
Actuellement, MySQL a trois moyen de produire un résultat ordonné :
- En utilisant un index couvrant toutes les colonnes demandées et ordonnées
- En utilisant un tri en mémoire
- En utilisant une table temporaire

Sergey Petrunia détaille le fonctionnement de chaque méthode. La meilleure reste toujours la technique des index couvrants : il faut créer un index avec toutes les colonnes utilisées dans la requête. De cette manière, MySQL ne va même pas lire les données sur le disque, puisqu'elles sont déjà dans l'index. Le gain est apréciable.

- How MySQL executes ORDER BY
Ecrire un commentaire
le 28/08/2007 à 22:09
Différentes sauvegardes pour MySQL
En supposant que vous ne voulez pas acheter de logiciel supplémentaire (eg, Zmanda), vous pouvez utiliser mysqldump (export) et/ou LVM (hot backup) pour vos besoins en sauvegarde. mysqlhotcopy n'est pas fait pour InnoDB. La réplication est aussi une bonne idée. Voici plus d'information sur chaque méthode.

Une revue du paysage de la sauvegarde de données MySQL, par un administrateur Oracle. Ceux qui connaissent cette technologie retrouveront un certain nombre de concept familier, déclinés à la sauce MySQL.

- MySQL backups for InnoDB, as an Oracle DBA
- mysqldump
- zmanda
- mysqlhotcopy
- LVM
Ecrire un commentaire
Jan Kneschke publie un tutoriel pour le proxy MySQL, destiné à séparer les requêtes SQL en fonction de leur impact : les écritures vont directement sur le maître, tandis que les lectures vont uniquement sur les esclaves. Cela permet de mettre en place une architecture de réplication sans modifier le code source de l'application amont (PHP ou autre) : le proxy MySQL se charge de faire la répartition entre les différents noeuds de l'architecture.

Dans le deuxième volet du tutoriel, Jan s'intéresse à des couples de requêtes classiques, comme les insertions avec colonne auto_increment, ainsi qu'à la mesure du lag de réplication.

- MySQL Proxy learns R/W Splitting
- MySQL Proxy: more R/W splitting
Ecrire un commentaire
[...] cela signifie que la population d'administrateurs de bases de données qui souhaitent gérer leurs données importantes sur MySQL est limité actuellement au nombre des DBA qui étaient déjà en train d'utiliser MySQL il y a 5 ans. Ce qui signifie que l'offre sur le marché est inférieure à la demande actuelle, d'un facteur de 5 à 10.

- Experience lags adoption: Why Oracle and SQL DBAs probably want to learn MySQL
Ecrire un commentaire
le 24/08/2007 à 21:41
Savoir gérer le lag de réplication
Un problème courant de la réplication MySQL est le lag, ou encore le retard entre le serveur maître et les serveurs esclave. La réplication est asynchrone, et les deux peuvent finalement être séparé d'une durée variable.

Dries Buytaert propose plusieurs approches pour gérer ce retard, à défaut de le corriger.

1. Exécuter les requêtes sur le maître, sauf en lecture seule
2. Passer en réplication synchrone (cluster MySQL, patch Google)
3. Utiliser un équilibreur de charge, ou un proxy
4. Utiliser le partitionnement et le sharding
5. Réécrire l'application pour qu'elle gère ce retard
6. Utiliser le modèle media wiki, où on teste le retard, et on attend qu'il se résorbe

- Database replication lag
- google-mysql-tools
- MySQL Proxy home
- Continuent Sequoia
Ecrire un commentaire
le 24/08/2007 à 15:12
Migration de MS Access à MySQL
Selon un récent sondage, plus de 20% des utilisateurs MySQL envisagent de migrer des applciations Microsoft Access vers MySQL dans les 12 prochains mois. Il y a malheureusement très peu de documentatino pour décrire les bonnes pratiques de ce type d'opération.

Ce document résume les discussions autour de la session MS Access Migration durant la rencontre 2007 MySQL User Group en Californie. Cette session a rassemblé un grand nombre d'utilisateurs MySQL, avec le but d'identifier les clés du succès lors de la migration d'applications Access vers MySQL.

- Migrating From MS Access To MySQL
Ecrire un commentaire
le 22/08/2007 à 13:55
Configuration de tri de MySQL
Peter Zaitsev expérimente avec la variable sort_buffer_size pour voir comment la vitesse de tri est affectée par cette variable. En partant d'une valeur minimum de 32 ko, et en montant la quantité de mémoire affectée au tri, Peter note que la vitesse de tri augmente, et que la complexité du tri décroit (moins de passes pour faire le tri).

Malheureusement, au dela d'une valeur entre 75 et 250 ko, le nombre de passe de tri continue de réduire, mais le temps de calcul augmente. sort_buffer_size est donc une variable à optimiser avec doigté.

Au passage, on peut surveiller l'impact des tris sur le système avec les variables d'état préfixées par sort : Sort_merge_passes, Sort_range, sort_rows, sort_scan.

- How fast can you sort data with MySQL ?
- MySQL Select and Sort Status Variables
- 5.2.5. Status Variables
Ecrire un commentaire
le 22/08/2007 à 13:50
Variables MySQL pour les performances
Pour gagner en performances avec MysQL, il y a quelques variables à connaître. Les plus importantes sont : key_buffer_size, innodb_buffer_pool_size, innodb_additional_mem_pool_size, innodb_log_file_size, innodb_log_buffer_size, innodb_flush_logs_at_trx_commit, table_cache, thread_cache et query_cache_size.

- Tuning MySQL Server to boost performance
- Automating MySQL- Best Practices Management
- MySQL Security Overview
LoadingChargement en cours