Archive for the ‘ Security ’ Category

Galera replication – how to recover a PXC cluster

Galera replication for MySQL brings not only the new, great features to our ecosystem, but also introduces completely new maintenance techniques. Are you concerned about adding such new complexity to your MySQL environment? Perhaps that concern is unnecessarily.

I am going to present here some simple tips that hopefully will let fresh Galera users prevent headaches when there is the need to recover part or a whole cluster in certain situations. I used Percona XtraDB Cluster (project based on Percona Server and Galera library + MySQL extensions from Codership) to prepare this post, but most if not all of the scenarios should also apply to any solution based on MySQL+Galera tandem you actually chose, whether these are binaries from Codership, MariaDB Galera Cluster or maybe your own builds.

Unlike standard MySQL replication, a PXC cluster acts like one logical entity, which takes care about each node status and consistency as well as cluster status as a whole. This allows to maintain much better data integrity then you may expect from traditional asynchronous replication while allowing safe writes on multiple nodes in the same time. This is though for the price of more possible scenarios where database service will be stopped with no node being able to serve requests.

Lets assume the simplest case cluster of nodes AB and C and few possible scenarios where some or all nodes are out of service. What may happen and what we have to do, to bring them (or whole cluster) back up.

Scenario 1

g1Node A is gracefully stopped. Likely for the purpose of maintenance, configuration change, etc.
In this case the other nodes receive “good bye” message from that node, hence the cluster size is reduced and some properties like quorum calculation or auto increment are automatically changed. Once we start the A node again, it will join the cluster based on it’s wsrep_cluster_address setting in my.cnf. This process is much different from normal replication – the joiner node won’t serve any requests until it is again fully synchronized with the cluster, so connecting to it’s peers isn’t enough, state transfer must succeed first. If the writeset cache (gcache.size), on nodes B and/or C has still all the transactions there were executed during the time this node was down, joining will be possible via (usually fast and light) IST. Otherwise, full SST will be needed, which in fact is full binary data snapshot copy. Hence it may be important here to determine the best donor, as shown in this article. If IST is impossible due to missing transactions in donor’s gcache, the fallback decision is made by the donor and SST is started automatically instead.

Scenario 2

g2Nodes A and B are gracefully stopped. Similar to previous case, cluster size is reduced to 1, hence even the single remaining node C forms aprimary component and is serving client requests. To get the nodes back into the cluster, you just need to start them. However, the node C will be switched to “Donor/Desynced” state as it will have to provide state transfer to at least first joining node. It is still possible to read/write to it during that process, but it may be much slower, depending how large state transfers it needs to send. Also some load balancers may consider the donor node as not operational and remove it from the pool. So it is best to avoid situation when only one node is up.

Note though, if you restart A and then B in that order, you may want to make sure B won’t use A as state transfer donor, as A may not have all the needed writesets in it’s gcache. So just specify the C node as donor this way (“nodeC” name is the one you specify with wsrep_node_name variable):

service mysql start --wsrep_sst_donor=nodeC

Scenario 3

g3All three nodes are gracefully stopped. Cluster is deformed. In this case, the problem is how to initialize it again. Here, it is important to know, that during clean shutdown, a PXC node writes it’s last executed position into the grastate.dat file. By comparing the seqno number inside, you will see which node is the most advanced one (most likely the last one stopped). Cluster must be bootstrapped using this node, otherwise nodes that had more advanced position will have to perform full SST to join cluster initialized from the less advanced one (and some transactions will be lost). To bootstrap the first node, invoke the startup script like this:

/etc/init.d/mysql bootstrap-pxc


service mysql bootstrap-pxc


service mysql start --wsrep_new_cluster


service mysql start --wsrep-cluster-address="gcomm://"

or in packages using systemd service manager (Centos7 at the moment):

systemctl start mysql@bootstrap.service

In older PXC versions, to bootstrap cluster, you had to edit my.cnf and replace previous wsrep_cluster_address line with empty value like this: wsrep_cluster_address=gcomm:// and start mysql normally. More details to be found here.

g4Scenario 4

Node A disappears from the cluster. By disappear I mean power outage, hardware failure, kernel panic, mysqld crash, kill -9 on mysqld pid, OOMkiller, etc. Two remaining nodes notice the connection to A node is down and will be trying to re-connect to it. After some timeouts, both agree that node A is really down and remove it “officially” from the cluster. Quorum is saved ( 2 out of 3 nodes are up), so no service disruption happens. After restarting, A will join automatically the same way as in scenario 1.

Scenario 5

Nodes A and B disappear. The node C is not able to form the quorum alone, so the cluster is switching into a non-primary mode, in which MySQL refuses to serve any SQL query. In this state, mysqld process on C will be still running, you can connect to it, but any statement related to data fails with:

mysql> select * from test.t1;
ERROR 1047 (08S01): Unknown command

Actually reads will be possible for a moment until C decides that it cannot reach A and B, but immediately no new writes will be allowed thanks to the certification based replication in Galera. This is what we are going to see in the remaining node’s log:

140814 0:42:13 [Note] WSREP: commit failed for reason: 3
140814 0:42:13 [Note] WSREP: conflict state: 0
140814 0:42:13 [Note] WSREP: cluster conflict due to certification failure for threads:
140814 0:42:13 [Note] WSREP: Victim thread:
THD: 7, mode: local, state: executing, conflict: cert failure, seqno: -1
SQL: insert into t values (1)

The single node C is then waiting for it’s peers to show up again, and in some cases if that happens, like when there was network outage and those nodes were up all the time, the cluster will be formed again automatically. Also if the nodes B and C were just network-severed from the first node, but they can still reach each other, they will keep functioning as they still form the quorum. If A and B were crashed ( due to data inconsistency, bug, etc. ) or off due to power outage, you need to do manual action to enable primary component on the C node, before you can bring A and B back. This way, we tell the C node “Hey, you can now form a new cluster alone, forget A and B!”. The command to do this is:

SET GLOBAL wsrep_provider_options='pc.bootstrap=true';

However, you should double check in order to be very sure the other nodes are really down before doing that! Otherwise, you will most likely end up with two clusters having different data.

Scenario 6

g6All nodes went down without proper shutdown procedure. Such situation may happen in case of datacenter power failure, hitting some MySQL or Galera bug leading to crash on all nodes, but also as a result of data consistency being compromised where cluster detects that each node has different data. In each of those cases, the grastate.dat file is not updated and does not contain valid sequence number (seqno). It may look like this:

cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 220dcdcb-1629-11e4-add3-aec059ad3734
seqno: -1

In this case, we are not sure if all nodes were consistent with each other, hence it is crucial to find the most advanced one in order to boostrap the cluster using it. Before starting mysql daemon on any node, you have to extract the last sequence number by checking it’s transactional state. You can do it this way:

[root@percona3 ~]# mysqld_safe --wsrep-recover
140821 15:57:15 mysqld_safe Logging to '/var/lib/mysql/percona3_error.log'.
140821 15:57:15 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140821 15:57:15 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.6bUIqM' --pid-file='/var/lib/mysql/'
140821 15:57:17 mysqld_safe WSREP: Recovered position 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a:2
140821 15:57:19 mysqld_safe mysqld from pid file /var/lib/mysql/ ended

So the last committed transaction sequence number on this node was 2. Now you just need to bootstrap from the latest node first and then start the others.

However, the above procedure won’t be needed in the recent Galera versions (3.6+?), available since PXC 5.6.19. There is a new option – pc.recovery (enabled by default), which saves the cluster state into a file named gvwstate.dat on each member node. As the variable name says (pc – primary component), it saves only a cluster being in PRIMARY state. An example content of that file may look like this:

cat /var/lib/mysql/gvwstate.dat
my_uuid: 76de8ad9-2aac-11e4-8089-d27fd06893b9
view_id: 3 6c821ecc-2aac-11e4-85a5-56fe513c651f 3
bootstrap: 0
member: 6c821ecc-2aac-11e4-85a5-56fe513c651f 0
member: 6d80ec1b-2aac-11e4-8d1e-b2b2f6caf018 0
member: 76de8ad9-2aac-11e4-8089-d27fd06893b9 0

We can see three node cluster above with all members being up. Thanks to this new feature, in the case of power outage in our datacenter, after power is back, the nodes will read the last state on startup and will try to restore primary component once all the members again start to see each other. This makes the PXC cluster to automatically recover from being powered down without any manual intervention!  In the logs we will see:

140823 15:28:55 [Note] WSREP: restore pc from disk successfully
140823 15:29:59 [Note] WSREP: declaring 6c821ecc at tcp:// stable
140823 15:29:59 [Note] WSREP: declaring 6d80ec1b at tcp:// stable
140823 15:29:59 [Warning] WSREP: no nodes coming from prim view, prim not possible
140823 15:29:59 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 2, memb_num = 3
140823 15:29:59 [Note] WSREP: Flow-control interval: [28, 28]
140823 15:29:59 [Note] WSREP: Received NON-PRIMARY.
140823 15:29:59 [Note] WSREP: New cluster view: global state: 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a:11, view# -1: non-Primary, number of nodes: 3, my index: 2, protocol version -1
140823 15:29:59 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
140823 15:29:59 [Note] WSREP: promote to primary component
140823 15:29:59 [Note] WSREP: save pc into disk
140823 15:29:59 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = yes, my_idx = 2, memb_num = 3
140823 15:29:59 [Note] WSREP: STATE EXCHANGE: Waiting for state UUID.
140823 15:29:59 [Note] WSREP: clear restored view
140823 15:29:59 [Note] WSREP: Bootstrapped primary 00000000-0000-0000-0000-000000000000 found: 3.
140823 15:29:59 [Note] WSREP: Quorum results:
version = 3,
component = PRIMARY,
conf_id = -1,
members = 3/3 (joined/total),
act_id = 11,
last_appl. = -1,
protocols = 0/6/2 (gcs/repl/appl),
group UUID = 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a
140823 15:29:59 [Note] WSREP: Flow-control interval: [28, 28]
140823 15:29:59 [Note] WSREP: Restored state OPEN -> JOINED (11)
140823 15:29:59 [Note] WSREP: New cluster view: global state: 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a:11, view# 0: Primary, number of nodes: 3, my index: 2, protocol version 2
140823 15:29:59 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
140823 15:29:59 [Note] WSREP: REPL Protocols: 6 (3, 2)
140823 15:29:59 [Note] WSREP: Service thread queue flushed.
140823 15:29:59 [Note] WSREP: Assign initial position for certification: 11, protocol version: 3
140823 15:29:59 [Note] WSREP: Service thread queue flushed.
140823 15:29:59 [Note] WSREP: Member 1.0 (percona3) synced with group.
140823 15:29:59 [Note] WSREP: Member 2.0 (percona1) synced with group.
140823 15:29:59 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 11)
140823 15:29:59 [Note] WSREP: Synchronized with group, ready for connections

Scenario 7

g7Cluster lost it’s primary state due to split brain situation. For the purpose of this example, let’s assume we have the cluster formed from even number of nodes – six and three of them are in one location while another three in second location (datacenter) and network connectivity is broken between them. Of course the best practice is to avoid such topology: if you can’t have odd number of real nodes, at least you can use an additional arbitrator (garbd) node or set higher pc.weight to some nodes. But when split brain happens any way, so none of the separated groups can maintain the quorum – all nodes must stop serving requests and both parts of the cluster are just continuously trying to re-connect. If you want to restore the service even before the network link is restored, you can make one of the groups primary again using the same command like in scenario 5:

SET GLOBAL wsrep_provider_options='pc.bootstrap=true';

After that, you are able to work on the manually restored part of the cluster, and the second half should be able to automatically re-join using incremental state transfer (IST) once the network link is restored. But beware: if you set the bootstrap option on both the separated parts, you will end up with two living cluster instances, with data likely diverging away from each other. Restoring network link in that case won’t make them to re-join until nodes are restarted and try to re-connect to members specified in configuration file. Then, as Galera replication model truly cares about data consistency – once the inconsistency will be detected, nodes that cannot execute row change statement due to different data – will perform emergency shutdown and the only way to bring them back to the cluster will be via full SST.

I hope I covered most of the possible failure scenarios of Galera-based clusters, and made the recovery procedures bit more clear.

Le point de vue d’ sur la loi renseignement


Hier mardi 5 mai, les députés ont voté l’adoption de la loi renseignement par 438 voix pour et 86 contre. En attendant la suite du processus législatif, Octave Klaba, fondateur et Chairman d’OVH, revient en détail sur les conséquences réelles de cette loi, pour les hébergeurs, les FAI et leurs clients.

OVH a menacé de s’exiler hors de France, si la loi renseignement était adoptée. La loi vient d’être votée par l’Assemblée nationale. Qu’allez-vous faire maintenant ?

Je souhaite d’abord m’exprimer sur la loi elle-même. Cette loi n’est pas bonne pour notre pays. Pourquoi ?
Parce qu’elle va changer nos comportements, notre manière de vivre au quotidien, notamment lorsqu’on utilise les téléphones et l’Internet. Nous allons avoir le sentiment d’être sur écoute constamment et cela va créer une psychose dans la population. Manuel Valls le Premier ministre disait « Nous sommes en guerre », et effectivement avec la loi renseignement, le stress vient d’être transmis à l’ensemble du pays. En bref, si le gouvernement voulait que la population se sente menacée, c’est réussi. Très rapidement et automatiquement, nous allons intégrer les mécanismes de l’autocensure.
Je pense qu’au contraire, le rôle du gouvernement est de gérer le pays et ses problématiques sans que cela ait un impact sur la population, sans provoquer un changement de nos comportements, sans modifier les habitudes, sans modifier nos libertés acquises ou notre manière de vivre au quotidien. Le gouvernement a décidé de nous lier tous à cet état d’urgence terroriste. C’est un fait. C’est un choix. Personne ne peut plus dire « moi dans mon village je me moque du terrorisme ».


63 % des Français pensent pourtant que cette loi n’est pas dérangeante parce qu’être écouté n’est pas grave quand on n’a rien à se reprocher. Quelles réflexions cela vous inspire-t-il ?

Nous vivons en démocratie. Le plus grand nombre décide pour le pays, les lois sont votées de manière démocratique par des personnes qui ont été élues et auxquelles nous avons décidé de donner le pouvoir. C’est dans ce type de système que nous avons choisi de vivre, il faut le respecter. Ceux qui ne sont pas contents, ceux qui veulent changer le système peuvent s’engager, créer de nouveaux partis politiques, participer à la vie publique et faire en sorte que ce genre de loi ne passe pas. C’est comme ça. Voilà.


Quelles sont les conséquences de cette loi pour les hébergeurs et les datacentres en France ?

OVH avec d’autres hébergeurs (AFHADS, Gandi, IDS, Ikoula, Lomaco, Online) ont alerté le gouvernement que si la loi renseignement passait telle quelle, elle serait extrêmement néfaste pour l’activité économique des datacentres en France. En effet, nous avons des clients qui ne sont pas uniquement français. Aussi notre activité se base sur la confiance que nos clients nous accordent en hébergeant leurs données dans nos datacentres.
Nous avons été invités par le gouvernement à discuter de la loi pendant deux jours. La première journée, il nous a été dit que les intérêts économiques ne primaient pas sur les problématiques antiterroristes. Le gouvernement ne voulait rien changer du tout.
Les choses ont évolué le lendemain et nous avons pu rédiger l’amendement pour l’activité d’hébergement. C’est a minima, c’est-à-dire que la loi n’allait pas être retirée et nous n’avons pas pu y inclure tout ce que nous voulions.
Mais la modification de la loi que nous avons obtenue nous permet aujourd’hui de dire que la loi est compatible avec les datacentres et l’activité d’hébergement.


Pourquoi la loi n’affecte-elle plus votre activité d’hébergeur en France ?

Habituellement c’est le juge qui demande de faire les écoutes. Il envoie une réquisition sur une cible précise et dans le cadre d’une enquête judiciaire. La loi renseignement permet d’effectuer les écoutes hors cadre juridique. Pour l’activité d’hébergeur, nous avons pu encadrer les conditions d’application de cette loi et réduire son champ d’action.

1) La loi s’applique uniquement dans le cadre de la lutte antiterroriste. Elle ne peut pas être appliquée pour d’autres cas, par exemple l’activisme politique. Uniquement pour les problématiques liées au terrorisme.

2) Les demandes doivent être ciblées et précises, comme dans le cadre d’une enquête judiciaire classique. On ne parle donc plus de boîtes noires installées au cœur des datacentres pour écouter toutes les communications, mais on parle d’une demande ciblée et limitée. Par exemple, on doit nous préciser l’IP ou l’e-mail qui doit être écouté. L’écoute est limitée dans le temps à 4 mois, renouvelables.

3) La demande ne peut porter que sur les métadonnées c’est à dire qui communique avec qui. Et donc la demande ne peut pas porter sur le contenu des communications elles-mêmes. Si la demande concerne une IP, les métadonnées consistent en une liste des IP qui se sont connectées sur l’IP écoutée. Si la demande est une boîte d’e-mail, les métadonnées sont une liste des adresses e-mails qui ont communiqué avec la boîte e-mail écoutée.

4) Comme dans le cadre d’une enquête judiciaire, la récupération des métadonnées doit être assurée par l’hébergeur lui-même. Il n’y a donc ni intervention d’une personne extérieure ni installation de boîtes noires au sein de datacentres.

5) L’exécution de la demande ne relève plus du cadre de l’urgence, c’est-à-dire qu’elle doit passer par une commission de contrôle qui doit donner son avis au préalable. Cela veut dire aussi que l’ensemble des documents partagés, les métadonnées, suivent des procédures strictes : tout est écrit et archivé, avec une traçabilité. L’ensemble de ces documents relève du secret Défense.


Donc, il n’y a pas de boîtes noires chez les hébergeurs ?

Non, chez les hébergeurs, il n’y a pas de boîtes noires. Précisons : lorsqu’on parle de boîtes noires, on parle d’écoute massive, permanente et totale. Ce n’est pas du tout le cas pour les hébergeurs.
Nous estimons que l’amendement que nous avons demandé ne règle pas l’ensemble des problèmes. Mais le champ d’application a été bien réduit.


Qu’en est-il pour les fournisseurs d’accès à Internet (FAI) ?

En plus d’être un hébergeur, OVH est aussi un fournisseur d’accès. Les deux activités utilisent deux réseaux séparés et isolés. Pour notre activité de fournisseur d’accès, nous sommes effectivement soumis à l’ensemble de la loi. C’est-à-dire qu’en tant que FAI, on pourra nous demander d’installer des boîtes noires sur notre réseau de FAI. La loi va, en effet, permettre de capter l’ensemble des échanges que la population effectue via les téléphones mobiles et Internet vers l’extérieur : vers les hébergeurs, vers Google, vers Facebook, vers tout.


Le FAI OVH a-t-il des boîtes noires ?

Non, nous n’en avons pas. Pas en tant qu’hébergeur, pas non plus en tant que FAI.
Par contre, techniquement parlant, lorsqu’on crée un réseau Internet, ce réseau passe par des NRA, par des bâtiments, par des villes et il est interconnecté à d’autres réseaux. Parfois, on utilise les réseaux tiers pour connecter nos équipements. Il est possible par exemple d’installer un coupleur sur une fibre optique et de copier, sans être vu, l’ensemble des informations qui passent par cette fibre. Techniquement parlant, on peut donc installer une boîte noire, en secret et à l’insu des fournisseurs d’accès.
Pour se prémunir il faut chiffrer les informations qui circulent entre les équipements avec par exemple la technologie MACsec. Ainsi, même si quelqu’un installe une boîte noire en secret, il ne pourra pas voir le contenu des échanges.
Il faut savoir aussi que, dans le cadre de la loi renseignement, si jamais les communications sont chiffrées par le gestionnaire du réseau, celui-ci pourra être obligé de fournir les clés de chiffrement aux équipes du Renseignement. En d’autres termes, le chiffrement permet d’éviter uniquement l’écoute passive à l’insu des FAI.


Le réseau FAI d’OVH est-il chiffré ?

Oui, mais pas en totalité. Aujourd’hui nous chiffrons une partie du réseau et progressivement nous allons installer le chiffrement sur l’ensemble de notre réseau, entre tous les routeurs et les switches pour éviter l’écoute passive à notre insu.


Finalement, que conseillez-vous à vos clients ?

D’abord, pour nos clients hébergement français et étrangers, il n’y a pas de changements, sauf si le client a une activité terroriste. En dehors de ce cas de figure, l’hébergement en France n’est pas impacté par la loi renseignement et tout continue comme avant.
Héberger les serveurs en dehors de la France n’évitera pas les écoutes chez les FAI français. Les visiteurs français de sites web passeront obligatoirement par ces FAI qui eux sont soumis à la loi renseignement. On peut bien sûr utiliser un VPN pour administrer son serveur mais on ne peut pas obliger 100% des visiteurs de sites web à utiliser un VPN juste pour consulter un site web.
C’est pourquoi OVH ne va pas arrêter ou réduire l’activité de ses datacentres en France. Nous allons poursuivre nos investissements prévus. Ceci dit, OVH a également un plan d’investissements pour la création de datacentres hors de France dans les 12 mois à venir : 3 nouveaux datacentres en Europe et 3 en dehors de l’Europe. L’annonce des pays et des lieux précis sera faite à l’OVH Summit.
Pour notre activité de FAI, nous travaillons sur notre box qui cache quelques bonnes surprises … je vous invite à suivre les annonces du Summit le 24 septembre prochain.

s3ql – a full-featured file system for online data storage

I am really impressed by my first look at s3ql. A really complete, just working and well documented tool to mount aws s3 and other cloud storage solution on a dedicated server:

S3QL is a file system that stores all its data online using storage services like Google Storage, Amazon S3 or OpenStack. S3QL effectively provides a hard disk of dynamic, infinite capacity that can be accessed from any computer with internet access running Linux, FreeBSD or OS-X.

S3QL is a standard conforming, full featured UNIX file system that is conceptually indistinguishable from any local file system. Furthermore, S3QL has additional features like compression, encryption, data de-duplication, immutable trees and snapshotting which make it especially suitable for online backup and archival.

S3QL is designed to favor simplicity and elegance over performance and feature-creep. Care has been taken to make the source code as readable and serviceable as possible. Solid error detection and error handling have been included from the very first line, and S3QL comes with extensive automated test cases for all its components.


  • Transparency. Conceptually, S3QL is indistinguishable from a local file system. For example, it supports hardlinks, symlinks, ACLs and standard unix permissions, extended attributes and file sizes up to 2 TB.
  • Dynamic Size. The size of an S3QL file system grows and shrinks dynamically as required.
  • Compression. Before storage, all data may compressed with the LZMA, bzip2 or deflate (gzip) algorithm.
  • Encryption. After compression (but before upload), all data can AES encrypted with a 256 bit key. An additional SHA256 HMAC checksum is used to protect the data against manipulation.
  • Data De-duplication. If several files have identical contents, the redundant data will be stored only once. This works across all files stored in the file system, and also if only some parts of the files are identical while other parts differ.
  • Immutable Trees. Directory trees can be made immutable, so that their contents can no longer be changed in any way whatsoever. This can be used to ensure that backups can not be modified after they have been made.
  • Copy-on-Write/Snapshotting. S3QL can replicate entire directory trees without using any additional storage space. Only if one of the copies is modified, the part of the data that has been modified will take up additional storage space. This can be used to create intelligent snapshots that preserve the state of a directory at different points in time using a minimum amount of space.
  • High Performance independent of network latency. All operations that do not write or read file contents (like creating directories or moving, renaming, and changing permissions of files and directories) are very fast because they are carried out without any network transactions. S3QL achieves this by saving the entire file and directory structure in a database. This database is locally cached and the remote copy updated asynchronously.
  • Support for low bandwidth connections. S3QL splits file contents into smaller blocks and caches blocks locally. This minimizes both the number of network transactions required for reading and writing data, and the amount of data that has to be transferred when only parts of a file are read or written.