• Créer un utilisateur ayant seulement les droits de lectures sur les bases :

mysql> GRANT SELECT ON *.* TO 'restorative_user'@'localhost' identified by 'password';

• Lui donner les droits complets UNIQUEMENT sur la base souhaitée :

mysql> GRANT ALL ON database2.* TO 'restorative_user'@'localhost';

• Lancer l’import avec l’option –force pour ignorer les erreurs d’accès refusé avec l’utilisateur donnée:

shell> mysql -u restorative_user -ppassword --force < /path/fulldump.db

Tout d’abord téléchargeons le scripte perl (vous allez voir, c’est sexy <3 ):

pegasus:~# wget mysqltuner.pl

Puis on le rend exécutable :

pegasus:~# chmod -x mysqltuner.pl

On fini par l’exécuter… :

pegasus:~# perl mysqltuner.pl

 >>  MySQLTuner 1.0.1 - Major Hayden
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.51a-24+lenny3
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 13M (Tables: 258)
[--] Data in InnoDB tables: 1M (Tables: 62)
[!!] Total fragmented tables: 32

-------- Performance Metrics -------------------------------------------------
[--] Up for: 22d 23h 36m 15s (1M q [0.553 qps], 86K conn, TX: 2B, RX: 202M)
[--] Reads / Writes: 69% / 31%
[--] Total buffers: 58.0M global + 2.6M per thread (100 max threads)
[OK] Maximum possible memory usage: 320.5M (8% of installed RAM)
[OK] Slow queries: 0% (0/1M)
[OK] Highest usage of available connections: 21% (21/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/2.0M
[OK] Key buffer hit rate: 99.7% (1M cached / 5K reads)
[OK] Query cache efficiency: 68.7% (516K cached / 752K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 36K sorts)
[OK] Temporary tables created on disk: 21% (6K on disk / 30K total)
[OK] Thread cache hit rate: 99% (49 created / 86K connections)
[!!] Table cache hit rate: 2% (64 open / 3K opened)
[OK] Open file limit used: 10% (105/1K)
[OK] Table locks acquired immediately: 99% (358K immediate / 358K locks)
[OK] InnoDB data size / buffer pool: 1.2M/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    table_cache (> 64)

Dans le cas de ce serveur, tout est bien configuré, à l’exception de la variable “table_cache” (on le voit au [!!]). Plus d’explications sont données dans la partie “Recommendations” à la fin du fichier. Il ne vous reste plus qu’à appliquer ces recommandations et ré-exécuter le script pour voir si tout est bon. Parfois, il faut l’éxectuer 3/4 fois avant d’avoir une configuration satisfaisante.

En gros : le mot de passe du script et celui importé son différent. Il est donc impossible de (re)lancer MySQL. Pas de panique, il existe une solution !

Affichez le fichier /etc/mysql/debian.cnf :

cat /etc/mysql/debian.cnf

Le mot de passe y est présent en clair sous la forme :

password = UIMK4oV80fUog0Ce

Il ne vous reste plus qu’à saisir la commande SQL ci-dessous afin de redéfinir le mot de passe :

GRANT SHUTDOWN ON *.* TO 'debian-sys-maint'@'localhost' IDENTYFIED BY 'LE_MOT_DE_PASSE_TROUVE';

Voilà, le tour est joué, vous pouvez reprendre vos activités d’administrateur bourrin en toute tranquillité !

La première solution serait un grep pour retrouver la chaine de caractère…

grep -rin "Chaine à rechercher" /ou/chercher

• -r pour la récursivité
• -i pour l’insensibilité à la casse
• -n pour ajouter le numéro de ligne devant chaque resultat
• … Puis on remplace à la main…

Si il n’y que quelques occurrences ce n’est pas très grave. Par contre, si il y a 35675 occurrences, c’est déjà plus embêtant. La solution que je vous propose est une simple commande perl. Elle permet de rechercher ET remplacer d’un coup :

perl -pi -w -e 's/mot_a_chercher/replacement/g;' *.php

• -p pour boucler
• -i pour remplacer
• -w pour afficher les warnings
• -e pour exécuter la commande qui suit;
• *.php est le patern des fichiers qui seront analysé. Ici, tout les fichiers ayant pour extension .php seront analysés.

Le principe est simple : vous choisissez vos applications parmis une liste contenant les applications les plus utilisés (Firefox, Google Talk, Flash, etc). Puis Ninite vous prépare un exécutable que vous téléchargés. Il ne vous reste qu’à lancer l’exécutable. Ce dernier téléchargera les installeurs et les exécutera. Pas mal non ?

Sans plus attendre, le lien ! http://ninite.com/

Concrètement, à chaque fois qu’un visiteur demande la page “www.exemple.com/index.php”, la page index.php est exécutée par Apache, qui renvoie une page web. Ce processus est gourmand et est à l’origine de l’augmentation du temps de réponse lorsque vous êtes soumis à une forte charge. Pour palier au problème, il suffit de mettre en place un système de cache : lieu d’exécuter index.php 36 000 fois, WordPress l’exécutera une fois et gardera en mémoire le résultat qui sera renvoyé aux utilisateurs.

Pour activer cette fonctionnalité, nous allons installer et activer le plugin WP-Cache :

1. Se connecter à WordPress [30s]
2. Dans le menu “Extensions” cliquer sur “Ajouter” [15s]
3. Rechercher WP-Cache [15s]
4. Cliquer sur “Installer” devant le résultat de la recherche “WP-Cache” [5s]
5. Le plugin s’installe et vous propose de s’activer. Activez le [30s]
6. Dans le menu “Réglages” cliquez sur “Wp-Cache” [10s]
7. Cliquez sur “Enable” [5s]

Le cache est activé, vous êtes en zone sûre en à peine 1min50s.

Avant de commencer, je précise ces opérations ne sont pas entièrement réalisables si vous n’avez pas d’accès complet à votre configuration DNS. C’est par exemple le cas pour la gestion du DNS chez OVH (TTL inchangeable).

La seul chose à connaitre est la notion de TTL (Time To Live). Le TTL est la durée de vie d’une valeur DNS envoyée par un serveur. Par exemple, si je demande “www.exemple.fr” à mon serveur DNS, il répondra : 123.123.123.123 (TTL = 3600s). Mon ordinateur ne redemandera par cette information avant 3600s.

Voici donc la façon propre de changer ces DNS :

1. Noter la valeur initiale du TTL (TTL1)
2. Baisser cette valeur à une durée minime (TTL2 de 1min soit 60s par exemple)
3. Attendre un laps de temps d’une durée supérieure à TTL1 de façon à être sur que toutes les machines possèdent la nouvelle valeur TTL2
4. Modifier l’entrée DNS (basculer de l’IP1 vers l’IP2)
5. S’assurer que tout fonctionne bien au bout d’une periode supérieure à TTL2
6. Une fois la modification validée, modifier le TTL pour le remettre à la valeur de TTL1
7. De cette façon, si une erreur ou une mauvaise configuration est propagée, elle ne l’est que pour une durée de TTL2 (1 min dans notre cas) et non pas de TTL1 (23h par exemple) et la rupture de service est moindre.

Ce Tip va porté sur mod_expires, un module apache permettant la mise en cache longue durée coté client. Ce module est très utile lorsque vous avez un contenu stable sur votre site. Par exemple, les images du thèmes, les Javascripts, les CSS. Le but est au final de transférer un minimum de donnés pour soulager le serveur Web. Sans plus attendre, l’utilisation !

On active le mode et on redémarre Apache pour en tenir compte:

pegasus:~# a2enmod expires
Enabling module expires.
Run '/etc/init.d/apache2 restart' to activate new configuration!
pegasus:~# apache2ctl restart

Il suffit ensuite d’ajouter les lignes suivantes à votre VHost :

  
    ExpiresActive On
    ExpiresDefault "access plus 1 month"
  

FilesMatch : Permet de choisir la liste des extensions à garder en cache
ExpiresActive : Active le tag d’expiration
ExpiresDefault : Permet de définir la durée de cache

Nous allons utiliser “Siege” : un petit utilitaire en ligne de commande, très simple d’utilisation. Il faut donc se le fournir.

Pour cela :

cd /tmp
wget ftp://ftp.joedog.org/pub/siege/siege-latest.tar.gz

Ensuite on l’installe :

tar xzvf siege-latest.tar.gz
cd siege-2.69
./configure
make
make install

Maintenant, on peut lancer le test de montée en charge.

siege -d1 -r300 -c100 -t1M www.le-site.com > log

Les options :

-d : temps en seconde de sleep entre les requêtes
-r : nombre d’utilisateurs simulés
-c : nombre de cliques par utilisateurs
-t : durée de la simulation (s pour seconde, M pour minute, H pour heure) FACULTATIF

On voit par la suite la liste de toutes les requêtes d’afficher :

HTTP/1.0 200   0.24 secs:    4679 bytes ==> /
HTTP/1.0 200   0.41 secs:    4720 bytes ==> /
HTTP/1.0 200   0.29 secs:    4677 bytes ==> /
HTTP/1.0 200   0.31 secs:    4755 bytes ==> /
HTTP/1.0 200   0.42 secs:    4533 bytes ==> /
HTTP/1.0 200   0.30 secs:    4719 bytes ==> /

Et à la fin, on obtient un résumé du benchmark :

Lifting the server siege...      done.                                                                                                                                                            Transactions:                     353 hits
Availability:                 100.00 %
Elapsed time:                   3.39 secs
Data transferred:               1.55 MB
Response time:                  0.40 secs
Transaction rate:             104.13 trans/sec
Throughput:                     0.46 MB/sec
Concurrency:                   41.98
Successful transactions:         353
Failed transactions:               0
Longest transaction:            3.30
Shortest transaction:           0.21

Et en plus vous avez le détail enregistré dans “log”.