Master-Slave

L'architecture Master-Slave est un modèle de conception distribuée où un nœud principal (master) maintient l'autorité et coordonne les opérations, tandis que des nœuds secondaires (slaves) répliquent les données et traitent les requêtes en lecture. Ce pattern est fondamental dans les systèmes de bases de données distribuées, les systèmes de stockage et les architectures à haute disponibilité, permettant la scalabilité horizontale et la tolérance aux pannes.

Fondements de l'architecture Master-Slave

• Le master gère toutes les opérations d'écriture et maintient l'état autoritaire du système
• Les slaves répliquent les données du master et traitent les requêtes en lecture pour distribuer la charge
• La synchronisation unidirectionnelle garantit la cohérence des données depuis le master vers les slaves
• Le basculement (failover) permet à un slave de devenir master en cas de défaillance du nœud principal

Avantages de l'architecture Master-Slave

• Scalabilité en lecture : distribution des requêtes de consultation sur plusieurs nœuds slaves
• Haute disponibilité : continuité de service même en cas de défaillance d'un slave
• Séparation des charges : isolation des opérations d'écriture et de lecture pour optimiser les performances
• Sauvegarde en temps réel : les slaves servent de copies de secours automatiquement synchronisées
• Réduction de la latence : possibilité de géolocaliser les slaves près des utilisateurs pour les lectures

Exemple concret avec PostgreSQL

import { Pool } from 'pg';

// Configuration Master-Slave pour PostgreSQL
class DatabaseCluster {
  private masterPool: Pool;
  private slavePools: Pool[];
  private currentSlaveIndex: number = 0;

  constructor() {
    // Pool de connexion au master (écritures)
    this.masterPool = new Pool({
      host: 'master-db.example.com',
      port: 5432,
      database: 'production',
      max: 20,
      idleTimeoutMillis: 30000
    });

    // Pools de connexion aux slaves (lectures)
    this.slavePools = [
      new Pool({ host: 'slave1-db.example.com', port: 5432, database: 'production', max: 50 }),
      new Pool({ host: 'slave2-db.example.com', port: 5432, database: 'production', max: 50 }),
      new Pool({ host: 'slave3-db.example.com', port: 5432, database: 'production', max: 50 })
    ];
  }

  // Opérations d'écriture sur le master
  async write(query: string, params: any[]): Promise<any> {
    const client = await this.masterPool.connect();
    try {
      return await client.query(query, params);
    } finally {
      client.release();
    }
  }

  // Opérations de lecture avec load balancing sur les slaves
  async read(query: string, params: any[]): Promise<any> {
    const slavePool = this.getNextSlave();
    const client = await slavePool.connect();
    try {
      return await client.query(query, params);
    } catch (error) {
      // Fallback vers le master si le slave est indisponible
      console.warn('Slave unavailable, falling back to master');
      return this.write(query, params);
    } finally {
      client.release();
    }
  }

  // Round-robin load balancing entre les slaves
  private getNextSlave(): Pool {
    const slave = this.slavePools[this.currentSlaveIndex];
    this.currentSlaveIndex = (this.currentSlaveIndex + 1) % this.slavePools.length;
    return slave;
  }

  // Exemple d'utilisation
  async createUser(email: string, name: string): Promise<void> {
    await this.write(
      'INSERT INTO users (email, name, created_at) VALUES ($1, $2, NOW())',
      [email, name]
    );
  }

  async getUsers(limit: number): Promise<any[]> {
    const result = await this.read(
      'SELECT id, email, name FROM users ORDER BY created_at DESC LIMIT $1',
      [limit]
    );
    return result.rows;
  }
}

// Utilisation du cluster
const db = new DatabaseCluster();

// Écriture sur le master
await db.createUser('user@example.com', 'John Doe');

// Lecture distribuée sur les slaves
const users = await db.getUsers(100);

Mise en œuvre d'une architecture Master-Slave

1. Identifier les besoins de scalabilité et la proportion lecture/écriture de votre application
2. Configurer la réplication depuis le master vers les slaves (streaming replication, log shipping)
3. Implémenter un mécanisme de routage pour diriger les écritures vers le master et les lectures vers les slaves
4. Mettre en place un système de monitoring pour surveiller la latence de réplication (replication lag)
5. Configurer un mécanisme de failover automatique (promotion d'un slave) avec des outils comme Patroni ou Keepalived
6. Tester régulièrement les scénarios de basculement et valider les temps de récupération (RTO/RPO)
7. Documenter la topologie et les procédures d'intervention en cas de défaillance

Outils et technologies associés

• PostgreSQL Streaming Replication : réplication native en temps réel
• MySQL Group Replication : réplication multi-master avec consensus
• Redis Sentinel : gestion automatique du failover pour Redis
• Patroni : haute disponibilité et failover automatique pour PostgreSQL
• ProxySQL : proxy intelligent pour le routage master/slave MySQL
• HAProxy : load balancer pour distribuer les connexions
• Pgpool-II : middleware de pooling et réplication pour PostgreSQL

L'architecture Master-Slave reste un pattern fondamental pour construire des systèmes distribués performants et résilients. En séparant intelligemment les charges de lecture et d'écriture, elle permet d'atteindre des niveaux de scalabilité et de disponibilité essentiels pour les applications modernes à fort trafic. Sa mise en œuvre rigoureuse, combinée à un monitoring proactif et des mécanismes de failover robustes, garantit une infrastructure capable de supporter la croissance tout en maintenant l'intégrité des données.