Archive

Articles taggués ‘cluster’

Réplication MySQL Master-Slave et Master-Master

19/12/2018 Comments off

Source: ResponsiveMind

replicationLa 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…

Un site web sur plusieurs serveurs avec load balancing

18/12/2018 Comments off

site web load balancing

En 2014 petit budget ne signifie pas nécessairement configuration bas de gamme et il est assez facile de faire tourner de grosses applications ou un grand nombr
e de sites internet pour quelques centaines, voire dizaines d’euros. En conséquence directe de la deuxième loi de Moore (qui annonce que la puissance des ordinateurs double tous les 2 ans) et de la guerre que se livrent les société d’hébergement, il est assez facile de se procurer 2 serveurs assez puissants pour bien moins cher qu’un seul serveur de la même puissance il y a 2 ans.

Cela explique que de plus en plus de société se tournent vers des configurations comportant plusieurs serveurs, avec une seule adresse présentée aux internautes. Ces configurations peuvent être plus ou moins complexes et dépendent à la fois des besoins et des ressources à allouer mais globalement ça ressemble à ça :

cluster-serveurs-load-balancing

De quoi se compose notre système ?

Je pense qu’il est nécessaire de détailler les éléments ci-dessus afin de comprendre leur rôle et la façon dont ils interagissent.

  • Internet : il s’agit du client, l’internaute qui accède au site internet ou à l’application;
  • DNS : lorsque le client veut accéder à une ressource sur internet, il fait appel à un serveur DNS pour faire la traduction entre le nom de domaine et l’adresse IP du serveur qui fournit la ressource. Ici le serveur DNS semble un peu hors sujet mais j’ai préféré l’inclure parce qu’il va jouer un rôle dans la mise en oeuvre que je vous proposerai par la suite;
  • Load balancer : bien souvent il s’agit d’un serveur reverse proxy qui se charge de répartir les requêtes entre les différents serveurs de la grappe, parfois il s’agit d’une configuration plus complexe. Pour les montages simples, le load balancing est attribué au serveur DNS, nous y reviendrons par la suite. Ce que vous pouvez constater ici c’est que notre load balancer est le seul serveur visible depuis le monde extérieur.
  • Serveurs web : nous avons ici une grappe de n serveurs (en fonction de la puissance demandée) dont le rôle est de traiter les requêtes et de renvoyer les ressources demandées. Les fichiers disponibles sur toutes ces machines sont strictement identiques. Bien souvent il s’agit même d’un cluster dans lequel tous les nœuds agissent comme une seule et même entité, parfois il s’agit de machines indépendantes qui ont un système de fichiers distribué tel que Glusterfs;
  • Cluster base de données : les principaux systèmes de gestion de base de données sont capables de fonctionner en cluster, même sur des environnements hétérogènes. Pour cette raison, quelque soit le nombre de serveurs sur lesquels les bases de données sont réparties, j’ai choisi de les faire apparaître comme un cluster et non comme des serveurs distincts;
  • Serveur de sauvegarde : il n’est peut-être pas nécessaire de s’étendre. Quel que soit le dispositif, il dispose d’une grande capacité de stockage et d’un accès à sens unique à l’un des serveurs applicatifs (s’ils ont tous les mêmes fichiers, inutile d’ouvrir une porte sur tous) et au cluster de base de données.

Lire la suite…

MySQL Master / Slave Replication

29/01/2016 Comments off

Source: Uptime Made Easy

Master Slave MySQL Replication Summary

Master / Slave replication in MySQL is a great way to store an exact replica of your database on another machine in another location as part of a disaster recovery plan.  Before setting up Master / Slave replication there are a few things to remember.

  • Writes – Writes to the master database should make it to the slave.  But writes to the slave will not make it to the master.  If you do write records to the slave database directly, be prepared to have to either recreate the records or back them up separately and recover them if the replication breaks.  Many times the only way to get the databases to replicate again is to backup the master and recover it over the top of the slave deleting anything that was in the slave database before.
  • Broken Replication – Writes made directly to the slave can cause the replication to break due to duplicate key rows, etc..  Always write to the master.
  • Reads – Reads should be possible from either server.  Many organizations will use replication so as to create another database to read from thereby taking the load of all of their select statements and reports off the master server.

 

MySQL Replication schemeMaster Slave MySQL Replication

Steps to Setup MySQL Master / Slave Replication

Prerequisites

We will be assuming that the following prerequisites are done prior to beginning the steps listed below:

  • MySQL has been installed on both the master and the slave servers
  • The slave server is able to communicate directly to the mysqld port (typically 3306) on the master server, meaning that there is no firewall, routing, NAT or other problems preventing communication.
  • You have an administrator MySQL user that can create users on both the master and the slave machines.
  • You have permissions to edit the /etc/my.cnf files on both machines and enough privileges to restart mysql.

That should be it!  Let’s begin setting it up.

Lire la suite…

MySQL – Migrate Users from Server to Server

29/01/2016 Comments off

mysql migrate usersSometimes we need to migrate our databases to a new MySQL server.  It is easy to move the databases, but without the users and their permissions, our new databases would be worthless.  Below is a step-by-step on migrating MySQL users to a new MySQL server

Step 1 – Create a Query List That We Can Use to Get Grants for All Users

I use these options so that I wouldn’t get any formatting characters that I would have to manually delete later.

  • -N skip column names in the output
  • -p password – Asks me to type the password so nobody can get it from the command line history
  • -s  silent mode – less formatting output that we don’t want like “|” and “-“

So, let’s get a list of the users in a query that we can use to get the grants.  Our query will be output into the “myfile” file

$ mysql -uroot -N -p -s > myfile
Enter password:
select Distinct CONCAT(‘show grants for `’, user, ‘`@`’, host, ‘`;’) as query from mysql.user;
quit

If we want to see what our query file look like, we can take a quick peek:

[root@classes-dev-mysql ~]# cat myfile
show grants for `user1`@`%`;
show grants for `user2`@`%`;
show grants for `user3`@`10.%`;
show grants for `user4`@`10.%`;
show grants for `jeff`@`10.%`;

Step 2 – Create the MySQL Grant File

We don’t have quite what we want and need yet.  We are looking for a query that will create all of our users on the new MySQL server.  We need to run the query that we just created and it will give us the query that we will use later to create the users.  It will create our grant permission statements in a file named “grantfile

[root@classes-dev-mysql ~]# mysql -uroot -N -p -s -r < myfile > grantfile
Enter password:

We can take a peek at what our grantfile contains:

$ cat grantfile
GRANT USAGE ON *.* TO ‘user1’@’%’ IDENTIFIED BY PASSWORD ‘5ea9af6g6t27032f’
GRANT ALL PRIVILEGES ON `database1`.* TO ‘user1’@’%’
GRANT USAGE ON *.* TO ‘user2’@’10.%’ IDENTIFIED BY PASSWORD ‘2a123b405cbfe27d’
GRANT SELECT ON `database1`.`table1` TO ‘user2’@’10.%’GRANT ALL PRIVILEGES ON *.* TO ‘user3’@’10.%’ IDENTIFIED BY PASSWORD ‘753af2za1be637ea’
GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO ‘user3’@’10.%’ IDENTIFIED BY PASSWORD ’08ad9be605rfgcb’…

Step 3 – Create Users and Grant MySQL Permissions on the New MySQL Machine

Now we are done working on the source machine.  We need to copy our file named “grantfile” over to the new machine.

$ scp grantfile myuser@mysql2.uptimemadeeasy.com:/home/myuser

Next, we login to the destination or the new MySQL machine that we are building and run the “grantfile” in MySQL to create our users on the new MySQL machine.

$ mysql -uroot -p < ./grantfile

That’s it.  As long as our databases are named the same in the new MySQL, our users should be ready to use the copy of the databases in the new MySQL machine.

Source: Uptime Made Easy

Installing A High Availability Web Server Cluster On Ubuntu 12.10 Using HAProxy, HeartBeat And Lampp

05/11/2015 Comments off

What is the main objective of this entire topology?

high availability web server clusterRedundancy and Load Sharing! Imagine a scenario where your single web server is receiving millions and millions of HTTP requests per second, the CPU load is going insane, as well as the memory usage, when suddenly “crash!”, the server dies without saying good-bye (probably because of some weird hardware out-stage that you certainly won’t have time to debug). Well, this simple scheme might lead you into a brand new world of possibilities

What is this going to solve?

Hardware Failures! We are going to have redundant hardware all over the place, if one goes down, another one will be immediately ready for taking its place. Also, by using load sharing schemes, this is going to solve our High Usage! issue. Balancing the load among every server on our “farm” will reduce the amount of HTTP request per server (but you already figured that out, right?).
Let’s set it up! Firstly, we’re not going to use a domain scheme (let’s keep it simple), make sure your /etc/hosts file looks exactly like the picture below on every machine:
#vi /etc/hosts
192.168.0.241   haproxy
192.168.0.39 Node1
192.168.0.30 Node2
192.168.223.147 Node1
192.168.223.148 Node2
192.168.0.58 Web1
192.168.0.139 Web2
192.168.0.132 Mysql

Lire la suite…

Categories: Système Tags: ,