--master-data ajoute un CHANGE MASTER TO dans le dump contenant les informations nécessaires au slave sur les logs (nom de fichier et position). Cette option implique--lock-all-tables qui bloquera toutes les tables pendant le dump.
Autoriser les connections MySQL distantes
Activer les logs binaires sur chaque serveur : log_bin = /var/log/mysql/mysql-bin.log dans le format mixed : binlog_format = mixed
Positionner un server-id différent sur chaque serveur (a priori, ne pas utiliser 0…)
Créer un utilisateur dédié pour la réplication sur chaque serveur avec le droit REPLICATION SLAVE :grant replication slave on *.* to repl@'%' identified by 'XXX';
Vous avez mis en place deux beaux serveurs MySQL avec un système de réplication master-slave qui vous offre des temps de réponse impressionnants et vous permet de dormir sur vos deux oreilles depuis quelques semaines. Mais voilà qu’un beau jour (de préférence un lundi matin tôt) vous vous rendez compte que vos deux serveurs ne présentent plus les mêmes données (de préférence depuis le vendredi précédent, environ 10 minutes après votre départ).
Pour une fois, ne faites pas confiance à ce bon docteur House, non ça n’est pas un lupus et personne ne va mourir (enfin je crois, en fait ça dépend aussi de votre boss). Il y a de grandes chances pour que vos serveurs soient tout simplement désynchronisés et même si les symptômes semblent catastrophiques, le mal est simple à traiter. Direction les urgences pour administrer un remède de cheval à vos serveurs (en français dans le texte, resynchroniser les bases de données) ! Lire la suite…
La réplication d’un base de données permet de disposer du même jeu de données à tout moment sur deux serveurs ou plus. MySQL permet d’automatiser la recopie des données entre une machine principale et plusieurs secondaires de façon unidirectionnelle (réplication master-slave) ou de façon bidirectionnelle entre 2 serveurs (réplication master-master). Dans ce tutoriel, nous allons mettre en place ces deux types de systèmes, le second étant une extension du premier.
Si vous n’avez pas lu mon article à propos de la création d’une architecture serveurs distribuée, je vous invite à le faire, et spécialement mon exemple de mise en en oeuvre avec 2 serveurs, vous comprendrez peut-être mieux l’utilité d’une configuration de ce type. Pour les plus pressées, sachez simplement que je proposais de créer 2 serveurs web accueillant chacun sa propre base de données, les données étant strictement identiques et chaque insertion ou modification de données étant immédiatement recopiée. Lire la suite…
I use fail2ban on my servers to protect them from would-be attackers, if you don’t your either insanely nieve to the fact that somebody wants in your system, or your just wanting to see if you can get hacked. Most of the attackers I would assume are just after another « bot » in their « net », or maybe a place to host files.
Durzo hosts a script that allows you to log the attacks on you into a mysql database with geocoding, I thought this would be cool to use as I could see from where I was being attacked. I then got this working and another script to display the table in a web page so I could view the data easily.
I then found some scripts from Google to pull data from MySQL in a geolocation table and generate an XML file used to import into Google Maps. With some tweaking and customizing, I now have a map with the geolocation data as markers on the map. Not all the markers are right on a building, but they are close enough for me to see the areas from which attacks are coming.
