wOueb by Romain DECKER / Another IT Guy Blog

Pour les allergiques à la ligne de commande (ça existe), et qui voudraient un outil simple et gratuit pour sauvegarder des bases de données MySQL, il existe phpMyBackupPro.

Très simple à installer (il suffit de déposer un répertoire sur un serveur d’hébergement PHP), phpMyBackupPro se présente sous la forme d’une application hébergée et accessible via un navigateur. Une seule instance est nécessaire pour sauvegarder plusieurs serveurs MySQL.

Sauvegarde de vos bases MySQL avec phpMyBackupPro

Au niveau des fonctionnalités, on retrouve :

• sauvegarde d’une ou plusieurs bases, avec ou sans les données (ou juste la structure),
• compression possible (gzip ou zip),
• sauvegardes planifiées,
• interface de management des backups (vue, restauration, download, suppression, etc.),
• sauvegarde possible vers un serveur FTP ou envoi du résultat par mail,
• disponible en plusieurs langues.

Configuration d'une sauvegarde planifiée

Ci-dessous, la vue de management des backups : ici, une seule sauvegarde présente.

Restauration d'une base de données MySQL

Vous pouvez également visualiser un résumé de vos bases de données, avec le nombre de tables et d’entrées totales, ainsi que la taille.

Informations sur les bases accessibles

Personnellement, je suis plus adepte de la ligne de commande, et pour la sauvegarde de serveurs MySQL, j’utilise un script très bien fait : AutoMySQLBackup.

Pour choisir, je dirais :

• si vous disposez d’un accès SSH à votre serveur, ainsi qu’au crontab, je privilégierais le script AutoMySQLBackup,
• si vous êtes sur un serveur mutualisé et que vous n’avez pas accès SSH/crontab, je préconiserais phpMyBackupPro.

Il est relativement facile d’installer un serveur MySQL, que ce soit pour faire un environnement de développement ou de production. En effet, un simple yum/apt-get/aptitude install mysql-server (suivant votre gestionnaire de paquets) vous installe en quelques minutes ce serveur de base de données avec une configuration par défaut.

Pourtant, un serveur MySQL n’est pas exploitable tout de suite : le mot de passe root n’est pas initialisé, des privilèges anonymes existent, etc. Il est préférable d’accorder de l’importance à la sécurité au début d’un projet, que d’essayer d’y revenir plus tard.

La commande mysql_secure_installation va apporter un minimum de sécurité pour vos nouvelles installations. Elle vous permet (selon vos choix) :

• de changer le mot de passe root,
• de supprimer les comptes anonymes,
• de désactiver la connexion du compte root à distance,
• de supprimer la base de données « test » à laquelle tout le monde peut avoir accès.

L’outil finit sur un rechargement des privilèges (« Flush privileges ») afin d’appliquer les changements de droits au serveur.

Pour lancer la commande : /usr/bin/mysql_secure_installation.

Sécurisation de base d'un serveur MySQL avec mysql_secure_installation

Bien entendu, ceci n’exclut pas une politique de sécurisation globale (présence d’un firewall, port MySQL changé, filtrage des privilèges par adresse source, etc.). Cette commande vous permet juste de passer sur les points critiques en quelques secondes.

Note : je traite uniquement de Linux, je déconseille l’utilisation de MySQL sur un OS Windows. Par ailleurs, je ne sais pas si la commande mysql_secure_installation existe sur Windows.

Facebook est une vraie machine de guerre : on a pu voir récemment que c’était le site le plus visité au monde, et tout ça seulement après quelques années. Contrairement à d’autres « supergrands » (Google, Microsoft, Apple, Youtube, etc.) un certain nombre d’informations filtrent lors de conférences, et dans des documents officiels.

Je rappelle que pour écrire ces 2 articles, j’ai simplement visionné des vidéos de conférences pour compiler les informations. Vu la masse de détails obtenus, j’ai publié deux articles :

• le précédent, présentant les chiffres clés sur l’infrastructure de Facebook,
• celui-ci : comment Facebook gère quotidiennement son (immense) infrastructure ?

En extrapolant plusieurs données (graphiques d’évolution, chiffres passés, etc.) on estime entre 60 000 et 100 000 le nombre de serveurs de Facebook .

Facebook : évolution du nombre de serveurs

Cependant, ce chiffre ne tient pas compte de deux nouveaux datacenters actuellement en cours construction (Oregon et Caroline du Nord).

Facebook a depuis longtemps atteint une masse critique qui nécessite de voir sa copie en terme d’administration quotidienne.

Un des ingénieurs de Facebook a bien illustré le problème lors d’une conférence :

With Facebook users spending a collective 8 billion minutes on the site each day, serving 1.2 million photos each second, and managing more than 25 terabytes of data per day in logging data, we’re forced to think about servers and datacenters differently.

Nb : les chiffres sont de 2009, les actuels sont présents dans mon article précédent.

(Lire la suite…)

Le moteur de base de données MySQL est très largement utilisé dans le monde. Même si l’installation et le paramétrage par défaut de MySQL suffit amplement pour un site web ou un blog, il est nécessaire de l’optimiser dans le cadre d’une utilisation plus « corporate« .

Deux leviers majeurs sont disponibles :

• l’optimisation du serveur de base de données (ou de la ferme de serveurs),
• l’optimisation du code.

La commande « show status » (en CLI, ou via phpMyAdmin) offre un certain nombre d’informations sur le statut d’un serveur MySQL.

MySQL : résultat de la commande show status dans phpMyAdmin

Cependant, les informations rendues ne sont pas toujours exploitables facilement (ni rapidement) pour les personnes qui ne sont pas DBA.

C’est là que mysqlreport intervient : c’est un simple exécutable qui va vous permettre de synthétiser le statut d’un serveur MySQL. Il suffit de télécharger ce fichier (pas d’installation nécessaire), et de le lancer en lui renseignant les paramètres de connexion au serveur MySQL, pour qu’il vous exporte un résultat assez sympa !

Jugez plutôt :

Pour ceux qui voudrait plus détails sur les valeurs obtenues et savoir comment les interpréter (et les comprendre), je vous invite à lire ceci : The guide to understand mysqlreport.

Facebook est une vraie machine de guerre : on a pu voir récemment que c’était le site le plus visité au monde, et tout ça seulement après quelques années. Contrairement à d’autres « supergrands » (Google, Microsoft, Apple, Youtube, etc.) un certain nombre d’informations filtrent lors de conférences, et dans des documents officiels.

J’ai visionné plusieurs heures de vidéos de conférences (long mais super intéressant) et ait compilé les informations. Vu la masse de détails obtenus, j’ai décidé de publier deux articles :

• celui-ci, présentant les chiffres clés sur l’infrastructure de Facebook,
• un second (à venir) : comment Facebook gère quotidiennement son (immense) infrastructure ?

En extrapolant

• certains graphiques d’évolution,
• des chiffres passés,
• des indications fournies pendant des conférences,

on estime entre 60 000 et 100 000 le nombre de serveurs de Facebook . Cependant, ce chiffre ne tient pas compte de deux nouveaux datacenters actuellement en cours construction (Oregon et Caroline du Nord).

Facebook : évolution du nombre de serveurs

Mais qu’est-ce qui peut bien tourner sur cette infrastructure ?

Données générales :

• 500 millions d’utilisateurs actifs (un utilisateur actif est un utilisateur qui se connecte au moins une fois par mois),
• 50% des utilisateurs se connectent au moins une fois par jour, soit 250 millions de personnes tout de même,
• 690 milliards de pages vues par mois,
• 6 milliards de contenus partagés par semaine (statuts, photos, liens, vidéos),
• 3 milliards de photos uploadées par mois, pour plus d’un pétaoctet de stockage uniquement destiné aux photos (chaque photo existe en 4 tailles),
• un dernier chiffre, le plus parlant peut-être : 16 milliards de minutes sont passées par jour sur Facebook. Ça représente 11 millions de jours ou encore plus de 30 000 années qui sont passées par jour sur le réseau social, c’est juste énorme !

Données techniques :

• plus de 300 To (téraoctets) de données en cache en RAM avec Memcached,
• 25 To (téraoctets) de log par jour,
• un ingénieur Facebook pour 1,1 millions d’utilisateurs. A titre de comparaison, Google emploi un ingénieur pour 190 000 utilisateurs,
• un opérateur Facebook pour 2,3 millions d’utilisateurs.

Quelques chiffres intéressants sur MySQL :

• 13 millions de requêtes par seconde en pic,
• 38 Go/s de trafic MySQL en pic,
• temps de réponse moyen en lecture : 4 ms,
• temps de réponse moyen en écriture : 5 ms,
• 450 millions de lignes lues par seconde en pic,
• 3,5 millions de lignes modifiées par seconde en pic,
• 5,2 millions d’I/O (disques) InnoDB par seconde.

Qui a d’autres chiffres intéressants et récents à partager ?

Dans le prochain article sur le sujet, je traiterai de la gestion quotidienne d’une infrastructure de cette taille.

Sources :

• A Day in the Life of Facebook Operations,
• Facebook on Bandwidth,
• MySQL Tech Talk.

J’ai cherché pendant quelques temps un moyen de sauvegarder proprement des bases de données MySQL, et j’ai trouvé mon bonheur avec AutoMySQLBackup.

Il s’agit d’un script (gratuit) qui permet de sauvegarder MySQL de façon récurrente en séparant les bases par fichiers, et en gardant des versions hebdomadaires, mensuelles, etc. Les fichiers obtenus sont directement compressés afin d’optimiser au maximum l’espace disque consommé. Il est possible de sauvegarder une ou plusieurs bases en particulier, ou alors toutes les bases du serveur.

Pour modifier les paramètres (connexion à la base de données, options, etc.), il suffit d’éditer le script (voir ci-dessous).

Et si vous voulez sauvegarder plusieurs serveurs de bases de données, pas de panique, il suffit d’avoir une version du script par serveur.

Enfin, pour une exécution régulière, il faut bien sûr le planifier avec crontab. Le résultat de chaque sauvegarde peut être envoyé par mail, sous la forme suivante :

Backup of Database Server – mysqlserver
======================================================================
Backup Start Time Wed Oct 27 20:45:01 CEST 2010
======================================================================
Daily Backup of Database ( information_schema )
Rotating last weeks Backup…
removed `/backups/mysql4/daily/information_schema/information_schema_2010-10-20_20h45m.Wednesday.sql.gz’

Backup Information for /backups/mysql4/daily/information_schema/information_schema_2010-10-27_20h45m.Wednesday.sql
compressed uncompressed ratio uncompressed_name
475 1232 67.0% /backups/mysql4/daily/information_schema/information_schema_2010-10-27_20h45m.Wednesday.sql
———————————————————————-
Daily Backup of Database ( cacti )
Rotating last weeks Backup…
removed `/backups/mysql4/daily/cacti/cacti_2010-10-20_20h45m.Wednesday.sql.gz’

Backup Information for /backups/mysql4/daily/cacti/cacti_2010-10-27_20h45m.Wednesday.sql
compressed uncompressed ratio uncompressed_name
171349 645053 73.4% /backups/mysql4/daily/cacti/cacti_2010-10-27_20h45m.Wednesday.sql
———————————————————————-
Backup End Wed Oct 27 20:45:20 CEST 2010
======================================================================
Total disk space used for backup storage..
Size – Location
140M /backups/mysql4

Vous, vous faites comment pour sauvegarder MySQL ?