❌

Vue lecture

↗️

Proton lance une fonctionnalité qui va vous convaincre de quitter Google

✇FrAndroid
Par :Corentin Béchade

L’entreprise suisse Proton, qui édite une suite logicielle centrée sur la vie privée, vient de déployer une nouvelle fonctionnalité intéressante pour celles et ceux qui cherchent une alternative à Google Doc.
 [Lire la suite]

Téléchargez notre application Android et iOS ! Vous pourrez y lire nos articles, dossiers, et regarder nos dernières vidéos YouTube.

  •  
  • ↗️
↗️

« La prudence est la meilleure des protections en ligne » : mythe ou réalité ? [Sponso]

✇Numerama.com
Par :humanoid xp

Cet article a été réalisé en collaboration avec Bitdefender

Les solutions de cybersécurité ne manquent pas. Mais, en avez-vous réellement besoin si vous faites preuve d’une vigilance à toute épreuve sur internet ?

Cet article a été réalisé en collaboration avec Bitdefender

Il s’agit d’un contenu créé par des rédacteurs indépendants au sein de l’entité Humanoid xp. L’équipe éditoriale de Numerama n’a pas participé à sa création. Nous nous engageons auprès de nos lecteurs pour que ces contenus soient intéressants, qualitatifs et correspondent à leurs intérêts.

En savoir plus

  •  
  • ↗️
↗️

H2DB - Mettre en place une réplication sur un cluster

✇Antichesse (o ^ω^ o)

Concept :

  • Vous avez une base H2 sur le réseau.
  • Vous en avez setupé une autre ailleurs sur le réseau.
  • Toutes les actions en écriture effectuées sur la première seront répliquées sur les autres. Ca nous fait donc des backups à pas cher.

Comment faire ?

  1. On démarre les instances A et B
# Instance A
java org.h2.tools.Server
    -tcp -tcpPort 9101
    -baseDir instance-A

# Instance B
java org.h2.tools.Server
    -tcp -tcpPort 9102
    -baseDir instance-B

Puis on démarre une troisième instance qui sera le cluster des deux autres :

# Cluster
java org.h2.tools.CreateCluster
    -urlSource jdbc:h2:tcp://localhost:9101/~/test
    -urlTarget jdbc:h2:tcp://localhost:9102/~/test
    -user sa
    -serverList localhost:9101,localhost:9102

Notre application se contentera de se connecter au cluster qui fera la réplication lui-même.

Nota Bene

  • Ce système ne marche pas avec une base embarquée !
  • Ce système effectue toujours les requêtes sur le premier nœud, le second n'est là que comme backup.

Et en cas de plantage ?

Simple, il suffit de :

  1. Se rendre sur le nœud qui est tombé.
  2. Dropper les datafiles.
  3. Relancer l'instance.
  4. Relancer le cluster (qui se chargera de répliquer tout sur l'instance remise à zéro).

Cette procédure de restauration peut prendre du temps sur les grosses bases mais je vois mal un SI de plusieurs tera-octets sur H2DB de toutes façons. Par contre, et au vu de la simplicité de configuration/installation de H2, ça peut être bien pour des BDD de moins de 32 Go

Pourquoi 32 Go et pas plus ?
Car avec une vitesse de réplication de 10 Mo / sec, ce qui est assez fréquent sur des petits VPS, la réplication des 32 Go prendra moins d'une heure, ce qui reste acceptable. Quant aux petites bases de moins de 1 Go, en 1 ou 2 minutes tout sera plié.

Pour peu qu'on ait mis en place un monitoring des instances et un rôle Ansible capable de restaurer les nœud déclenché par un hook, alors la procédure peut se faire automatiquement et sans effort, et j'aime le DevOps facile :D
— Liens directs

  •  
  • ↗️