nyroBlog
Ban NyroBlog, by DëuG
Image by DëuG - ?

Tag: PHP


Backup and Restore MySQL Database through command line

When you want backup a MySQL database, you don't have many solutions.

You can use PhpMyAdmin to backup the database but you will figured out that the export doesn't work so good: there is some information lacks like the Foreign key or other things like that. You'll also occur timeout problem when trying to backup -and restore- huge database.

You can also read a fex pages in the MySQL doc and you'll find Bash command to do exactly what you want. In only 1 line you'll be able to backup you're whole database in one text file.

Here is the backup command:

mysqldump --user=USER --password=PASS --add-drop-table DATABASENAME

This command show you all the MySQL query to execute to retrieve your entire database: the CREATE instructions, adding the constraints if needed and of course, the INSERT lines. The option --add-drop-table add the instruction to delete the table just before their creation: very useful to don't worry about cleaning the database before the backup.

If you want save more than one database, you have to replace DATABASENAME by --databases DATABASENAME1 DATABASENAME2 DATABASENAME3.

And if you want save all the database in you server, you can use --all-databases instead. Be sure the user used in the command line have access to all the databases you want back up.

Right now the command show you the query. Even if you're Flash Gordon, you can't do anything with that. A simple pipe to a file will save everything for you:

mysqldump --user=USER --password=PASS --add-drop-table DATABASENAME > DUMP.sql


To restore the database -or create it in an other server-, you have simply to upload the file saved just before and run this command in the same place of this file:

mysql -u USER --password=PASS DATABASENAME < DUMP.sql

PHP/MySQL: Howto paged with a random order

The problem is simple: we have to list randomly data from a MySQL table, by creating a paging.

Let's start with the basis: A normal paging. To do so, you use the LIMIT parameter in the MySQL query:

SELECT * FROM user LIMIT 20,10

Where we show the second page for the users with 10 elements by page.

You will probably order the result to be easier to use. For example:

SELECT * FROM user LIMIT 20,10 ORDER BY name ASC

At this point, everything was pretty easy and you probably already knew that.

Now we want to randomly order the result. Intuitively, you will do something like:

SELECT * FROM user LIMIT 20,10 ORDER BY RAND()

Which is not totally wrong. The problem with this solution will occur when changing the page, the order will be different -for sure, it's random. By changing the page you will probably see some recurrent data, and the visitor will never see all the result by reading all the pages. That's not expected.

The solution consists to generate a random number in PHP, stores it in a session variable, and finally use it in the MySQL query inside the RAND parenthesis. And it's finish. Therefore the random number used is every time the same for the visitor session, and the global order will stay the same in the differents pages.

The PHP code to generate and stored the random number:

$rand = $_SESSION['rand'];
if (empty($rand)) {
srand((float)microtime()*1000000);
$rand = "0.".rand();
$_SESSION['rand'] = $rand;
}

Of course, you have to open the session with session_start() at the top of your PHP script before every out or header send -or you can use ob_start().

Finally the MySQL query becomes:

SELECT * FROM user LIMIT 20,10 ORDER BY RAND($rand)

Voilà, you can make pagination with random order.

Version française de ce billet

MySQL : Multiples tris et sous-requêtes

Un petit truc en MySQL qui j'en suis sûr servira à plus d'un.

Pour California Apparel News, cela fait plusieurs fois que j'utilise cette technique qui marche à merveille.

Le problème est le suivant : Comment récupérer les 10 derniers ajouts d'une table mais triés par ordre alphabétique ?

La solution qui vient tout de suite à l'esprit est :

SELECT * FROM table ORDER BY date DESC, titre ASC LIMIT 0,10

On récupère bien les 10 derniers résultats, mais ils ne sont en aucun cas triés par ordre alphabétique. En effet, le tri se fait d'abord sur la date dans l'ordre décroissant, puis sur le titre. Le tri sur le titre ne sera effectif que si on a des éléments à la même date. Un exemple de ce qui pourrait sortir de cette requête est :

  • 11/01/2008 - Il fait beau à Los Angeles
  • 09/01/2008 - Nuageux mais pas froid à LA
  • 03/01/2008 - Il pleut à Los Angeles
  • 03/01/2008 - Tempête sur Los Angeles

(Bon que 4 résultats, je ne me souviens pas d'autres choses niveau météo ici)

On a les bons résultats, mais pas triés correctement. Alors c'est sûr, on pourrait écrire une fonction PHP pour trier les résultats et c'est bouclé. Mais une fonction de tri n'est jamais évidente à écrire et trier dès la requête augmentera les performances.

La solution est d'utiliser une sous-requête dans la clause FORM; la sous-requête récupèrera les 10 derniers résultats, la requête principal les triera par ordre alphabétique. La requête complète :

SELECT * FROM (SELECT * FROM table ORDER BY date DESC LIMIT 0,10) AS subSelect ORDER BY titre ASC

Noter le AS subSelect qui est indispensable, comme indiquée dans la doc.

Le résultat sera :

  • 11/01/2008 - Il fait beau à Los Angeles
  • 03/01/2008 - Il pleut à Los Angeles
  • 09/01/2008 - Nuageux mais pas froid à LA
  • 03/01/2008 - Tempête sur Los Angeles

La différence entre les 2 résultats est minime, mais vous avez compris !

Nous voilà donc avec nos résultats tout bien trié comme on le voulait !

J'ai utilisé ça à 2 endroits :

En espérant que vous aurez l'occasion d'utiliser cette petite technique qui gagne du temps.

Tutoriel : Transférer son site

Comme j'ai transférer mes 2 sites la semaine dernière, le sujet est tout chaud pour moi.

Avant de m'atteler à la tâche, j'ai chercher un petit tuto comme celui-ci, qui m'aurait permis de noter tous les points à ne pas oublier. Comme je n'ai pas trouver, je l'écris pour qu'un tel article existe !

Introduction

Commençons par poser le problème, histoire que tout le monde comprenne de quoi on parle.
Lorsqu'on veut publier un site internet sur la toile, on a besoin de 2 choses : un nom de domaine et un espace disque (serveur ou simple hébergement. Le terme serveur sera utilisé par la suite) dans lequel on stockera les fichiers du site.

Le nom de domaine est l'adresse avec laquelle vous accéder au site internet; nyrodev.info pour ce blog par exemple. Ce nom de domaine doit diriger votre visiteur sur vers votre serveur pour ainsi accéder au fichier. Votre serveur est accessible avec une addresse IP unique sur la toile. La liaison entre le nom de domaine se fait grâce aux DNS. Les DNS sont des ordinateurs sur la toile que n'importe qui peut interroger pour connaître l'adresse IP attribué à un nom de domaine.

Le serveur est là où sont stockés vos fichiers. Il s'agit ni plus ni moins que d'un ordinateur avec des logiciels spéciaux d'installés. Un serveur peut contenir plusieurs sites. Ce qui veut dire que plusieurs noms de domaines pointeront sur ce même serveur. L'affichage des bons fichiers se fera par le biais d'un panel de logiciel bien paramétrer pour chaque site. Cette partie ne sera pas traité dans ce billet. Dans la plupart des cas, les serveurs dédiés proposent des outils d'administration qui configure automatiquement tous ces logiciels serveurs pour vous à la création d'un nouveau site.

Notre but est de changer de serveur. Nous devrons donc transférer les fichiers du site (images, pages html, etc...), les base de données éventuelles et bien plus encore. Au final, nous changerons l'adresse IP sur laquelle point le nom de domaine pour utiliser le nouveau serveur.

Voyons donc quelles actions doivent être réaliser et dans quel ordre pour que tout se passe bien, en perdant un minimum de visiteurs durant le transfert.

Dans la suite du billet :
  • domaine.com : le nom de domaine à transférer
  • Serveur A : ancien serveur, sur lequel le nom de domaine pointe actuellement
  • Serveur B : nouveau serveur

1. Préparer le terrain

La première étape de ce transfert est de préparer le serveur B à recevoir le nouveau site. Créer le site dans votre administration afin de lui allouer un espace. Vous pouvez lui attribuer tout de suite domaine.com, ce sera toujours ça de gagner, avec les paramétrages des serveurs de mail, de FTP, etc... Cela ne pose pas problèmes[1] puisque domaine.com pointe toujours sur l'ancien serveur.

Ensuite, vous pouvez créer tous vos emails et redirection d'emails que vous avez sur le serveur A de façon à ne perdre aucun email. Pour les base de données, créez simplement les base de données sans les tables, cette partie fera l'objet d'une autre partie.

2. Transférer les fichiers

A ce stade là, vous pouvez transférer vos fichiers statiques. Ne transférer pas dès maintenant les fichiers uploadés par les visiteurs car le site est encore accessible, et donc des uploads peuvent encore avoir lieu.

Si vous avez un accès en SSH sur votre serveur A, pourquoi ne pas créer une archive tar.gz pour tout regrouper dans un seul fichier compressé, pour gagner du temps ?
Déplacer vous dans votre répertoire contenant vos fichiers, et pour créer l'archive :
tar cvzf dossier.tar.gz dossier
Récupérer ce fichier par FTP, et transférer le sur le serveur B, sur lequel vous devrez aussi avoir un accès SSH. Dans le dossier où vous avez uploadé cette archive, décompressez vos fichiers :
tar xvzf dossier.tar.gz
Ces fichiers contiendront peut-être des configurations pour accéder à la base de donnée, des fichiers .htaccess avec des répertoires absolus, etc... Autant de configurations qui seront sans doute différent sur le nouveau serveur. Modifier les maintenant.

Si vous n'avez par accès en SSH, rapatriez simplement tous vos fichier par votre FTP normalement. Vous pouvez faire les changements de configurations avant de les transférer.

De plus, pensez aux droits des dossiers dans lesquels vos scripts écrivent vos fichiers.

A ce stade là, vous devez avoir votre site prêt à fonctionner, en ajoutant simplement vos bases de données.

3. Fermeture temporaire du site

Pour être sûr de ne perdre aucune donnée durant le transfert, nous allons empêché complètement l'accès au site sur le serveur A, avant de transférer tous les fichiers dynamiques et les base de données.

Nous allons fermer la totalité du site avec un simple fichier .htaccess, interdisant tout et redirigeant sur une simple page texte pour dire que le site déménage. Le fichier .htaccess est :
Deny from all

    Allow from all

ErrorDocument 403 http://www.domain.com/transfert.php
Et créer votre fichier transfert.php qui explique que c'est temporaire et ne devrait pas durer plus de 24h.

4. Transfert des derniers éléments

Une fois le site fermé, vous pouvez transférer vos fichiers dynamiques, uploadés par vos utilisateurs. Vous pouvez être sûr qu'il n'y en aura plus de nouveaux.

Passons au transfert de la base de donnée.

Si vous n'avez pas d'accès à SSH, utilisez simplement phpMyAdmin pour exporter votre base sur le serveur A et l'importer dans le serveur B.

Mais si vous accès en SSH, il est préférable de procéder différemment pour 2 raisons : l'export de phpMyAdmin est parfois buggé, et si votre base de donnée est trop grosse, phpMyAdmin donnera des erreurs dues au timeout du PHP.

Donc nous avons besoin ici de deux ligne de commandes. La première pour exporter dans un fichier texte :
mysqldump --host=localhost --user=LOGIN --password=PASSE --add-drop-table NOMBASE > base.sql
Transférer ensuite le fichier base.sql sur le serveur B, et exécutez cette commande :
mysql -h localhost -u LOGIN --password=PASSE BASE < base.sql
Votre site doit maintenant être totalement opérationnel sur le serveur B. Si vous pouvez, un petit test ne fera pas de mal, pour être bien sûr.

5. Modifier le DNS

Enfin, il ne vous reste plus qu'à effectuer les modifications de votre nom de domaine pour qu'il pointe sur le serveur B, en modifiant l'adresse IP des DNS de ce dernier. Et puis patienter pour tester si tout est ok. Pour teste plus rapidement si tous vos paramètres sont bons et si tout se passe bien, je vous conseille fortement d'utiliser les serveur DNS d'Open DNS sur votre ordinateur (et pourquoi pas les garder par la suite ?). L'avantage d'Open DNS est qu'ils sont très rapide à se mettre à jour, et que vous pouvez le forcer à rafraîchir son cache. Faites-le donc pour votre site 15 à 20 minutes après avoir effectuer vos changements.

S'ils pointent sur la nouvelle IP, rafraichissez les DNS de votre ordinateur. Pour Windows: Démarrez > Exécuter > cmd. Puis la ligne de commande :
ipconfig /flushdns

Et tester dans votre navigateur préférer pour voir si tout est bon, ce qui est devrait être le cas.

Durant les jours qui suivent, vous devrez récupérer des emails sur les deux serveurs, en attendant que les DNS soient à jour partout.

Voilà, j'espère que ce tutoriel vous sera utile. Bien sûr il existe différentes méthodes à chaque étape. J'ai simplement présenter celles que j'ai utiliser et qui ont marcher parfaitement pour moi.
Si vous avez des remarques, questions, feedbacks, les commentaires sont là pour ça !

Merci à Niko qui m'a conseillé lors de mes transferts.

[1] : Le seul problème qu'il peut y avoir (et qui m'est arrivé) et si sur le serveur B, vous avez d'autres sites qui envoient des mails sur domaine.com. En effet, le serveur ne perdra pas de temps à l'envoyer à l'extérieur, puisque pour lui, ce nom de domaine lui appartient. Ce n'est un problème que si on ne le sait pas. Comme vous allez au final récupérer vos emails sur ce serveur, vous les aurez quoiqu'il arrive plus tard. Un petit webmail pour vérifier tout ça durant le transfert et tout est bon.

English Version of this post

Et si on restait 6 mois de plus ?

Histoire de ma vie de tous les jours à Los Angeles pendant mon stage.

Une dizaine de jours sans nouvelles. Mais que s'est-il donc passer pendant ce temps ? Je réfléchissais. Et comme ma décision est prise, je peux la partager maintenant.

Tout commence lundi il y a deux semaines, le patron Mike me demande comment se passe mon stage, si je suis content etc etc... Je lui réponds que oui, les gens sont géniaux et que le boulot est sympa, mais pas assez de programmation selon moi, je voudrais un peu plus de PHP...

Il me réponds qu'il en prend note. Et il ajoute une petite question, anodine : est-ce que tu veux rester après ton stage ? La question à laquelle je n'avais pas songer une seule seconde, je me voyais déjà rentré pénard dans 2 mois à la fin janvier, pour un mois de vacances et reprendre les cours à l'UTBM doucement en mars. Mais là, ça change la donne.

Avant de répondre, j'ai d'abord cherché sur internet si mon VISA me permettait de rester ou pas, et de travailler. La réponse est non. Je peux rester que 30 jours après la fin de mon stage, et pas pour travailler mais pour faire le touriste. Je mail Aquarius pour savoir s'il existe un moyen d'étendre le stage ou pas, j'aurai la réponse plus tard. Un mail aussi à l'UTBM pour savoir ce qu'il est possible de faire, si je peux interrompre mes études...

Je réponds à Mike avec toutes ces infos et commence à réfléchir, tout en modifiant quelques sites. Est-ce que je veux rester là plus longtemps ? qu'est-ce que ça changera ? Pour combien de temps ?...

Le lendemain, réponse d'Aquarius : Oui, je peux étendre mon Visa mais je devrai rentrer en France et repasser par la case remplissage de formulaire pour le VISA et passage à l'ambassade pour demander un nouveau VISA. Mais je ne dois pas tarder pour faire ces demandes. Dans le même temps, réponse de l'UTBM : oui, je peux interrompre mes études pour un projet personnel (UV intitulé ST00 à l'UTBM) qui ne me rapporte rien pour l'école. C'est juste 6 mois pour lesquels on peut faire ce qu'on le veut, du moment que c'est un peu fondé.

Bon, c'est possible, mais je devrai réécrire pas mal de papiers, en regroupé tout un tas, repasser par la petite séance de stress de l'ambassade (quoique, si ça se passe comme la 1ère fois...), rester encore 6 mois de plus loin de mes amis, ma famille, notre belle région.

Mais d'un autre côté je bosse dans une boîte à Los Angeles avec des gens sympa, mon anglais s'améliore encore, je peux voir l'océan tous les jours (les bureaux déménagent le mois prochain avec vue sur le coucher de soleil...) et je pourrai dire : "J'ai vécu un an à Los Angeles quand j'étais jeune.", c'est toujours mieux que 6 mois.

Durant ces 2 dernières semaines, je me suis donc poser la question tous les jours, changeant d'avis le matin au lever pour avoir l'avis totalement contraire le soir-même. Mais plus ça avançait, plus ma décision s'avérait claire...

Et j'ai donné ma réponse finale ce matin : "Je reste".

Donc pour ceux que ça intéresse, voilà mon programme pour les 8 prochains mois :

  • Retour en France le 26 janvier comme initialement prévu pour assistr au gala de la Gym de Thise :d
  • Durant 2 semaines, ça va être la course : ambassade des US à Paris, fiesta avec les amis, repas avec la famille, couper les cheveux et plein de petites choses à faire...
  • Départ pour Los Angeles vers le 13 ou 14 février
  • Retour au boulot le 18 février pour 5 mois
  • Arrêt du stage le 11 juillet
  • Retour définitif en France vers la fin juillet/début août

Alors ce soir, c'est remplissage des formulaires, envoie des mails pour demander des documents à droite à gauche et encore des infos.

Bon et maintenant, il faut vraiment que j'écrive mon billet sur Alcatraz...