L’auteur raconte comment son équipe a migré plus d’un milliard d’enregistrements d’une base de données critique (contenant des données financières) vers une nouvelle, sans aucune interruption de service. Voici les étapes clés et les leçons apprises :

1. Migration par lots des données historiques : Les données ont été divisées en chunks par plages d’ID, chargées en parallèle avec les index et contraintes désactivés pour accélérer le processus, puis vérifiées par des checksums pour garantir l’intégrité.

2. Écritures doubles (dual writes) : Pendant la migration, chaque nouvelle écriture était dupliquée vers l’ancienne et la nouvelle base. Les échecs étaient gérés via une file Kafka de réessai, avec des écritures idempotentes pour éviter les doublons.

3. Lectures fantômes (shadow reads) : Les requêtes étaient exécutées en silence sur la nouvelle base et comparées à l’ancienne pour détecter des incohérences (fuseaux horaires, collations, valeurs NULL), permettant de corriger les problèmes avant de basculer les utilisateurs.

4. Bascule progressive (cutover) : La nouvelle base a été préchauffée (cache et index), et le basculement a eu lieu à 4h30, heure de faible trafic, avec un mécanisme de retour arrière (rollback) prêt. Les métriques business et techniques ont été surveillées en temps réel.

5. Observabilité totale : Des tableaux de bord ont suivi la latence, le lag de réplication, les deadlocks, et les KPI métiers pour détecter instantanément tout problème.

Leçons clés :

• Les migrations à grande échelle se font par lots parallèles, avec des mécanismes de reprise et de vérification.
• Les dual writes et les shadow reads sont essentiels pour capturer les données en temps réel et valider la nouvelle base.
• La bascule doit être préparée comme une opération critique : cache préchauffé, monitoring obsessionnel, et plan de rollback.
• Une migration réussie repose sur la conception distribuée (idempotence, files de réessai) et une observabilité fine (WAL, cache, deadlocks).

En traitant la migration comme un problème de system design plutôt que technique, l’équipe a pu garantir une transition sans temps d’arrêt, malgré la pression et les risques financiers.

L'auteur détaille sa migration d’infrastructure en 2025, marquée par l’abandon de Proxmox au profit d’Hyper-V, principalement pour des raisons de performances et de gestion des sauvegardes : ZFS et PBS (Proxmox Backup Server) étaient devenus inadaptés à ses besoins, avec des vitesses de backup limitées à 100-150 Mbps contre 2 Gbps avec Hyper-V et Veeam, essentiel pour ses 7-8 To de données quotidiennes. Son infrastructure repose désormais sur deux serveurs sous Windows Server 2022 : un Supermicro X10SDV-4C-TLN4F (stockage NVMe et HDD en RAID 1) pour l’hyperviseur et un vieux HP MicroServer Gen8 (mis à niveau réseau et stockage) pour les backups, le tout protégé par un UPS APC reconditionné. Les VM, majoritairement sous Debian 12, incluent Ansible (avec Semaphore), LibreNMS, Home Assistant, Paperless-ngx, Jellyfin, Passbolt, Proton-backup, Wazuh et un serveur web. Le réseau est entièrement en 10 Gbps (catégorie 6 STP), avec un firewall OPNsense sur un NUC Intel N100. L’automatisation via Ansible/Semaphore gère mises à jour, backups (local, disques externes rotatifs, Backblaze B2 chiffré) et monitoring, respectant la règle 3-2-1. Il évoque aussi son wiki technique (xWiki) et son désengagement partiel du blog, critiquant l’impact des IA (comme Gemini) sur la visibilité des contenus humains, tout en reconnaissant leur utilité ponctuelle pour la veille ou l’écriture de scripts. Enfin, il souligne la désaffection des blogs au profit des réseaux sociaux et de l’IA, sans pour autant fermer son espace.

L'article décrit le passage d'un NAS Synology à un NAS Asustor, motivé par l'évolution des besoins en stockage et les limitations des produits Synology. L'auteur explique que Synology a stagné en termes de matériel et de logiciel, devenant coûteux et restrictif, notamment avec l'obligation d'utiliser des disques durs Synology pour les nouveaux modèles. Après une analyse approfondie des alternatives, il opte pour un NAS Asustor Lockerstor 10 Gen 3, plus puissant et offrant une meilleure flexibilité. Le nouvel appareil, bien que plus cher, se révèle plus rentable grâce à une capacité de stockage accrue et des performances supérieures. L'auteur partage ses premières impressions positives sur le système d'exploitation ADM d'Asustor, malgré quelques bugs mineurs et une interface moins intuitive que celle de Synology.

L'auteur utilise une histoire pour rappeler que les migrations Doctrine sont à privilégier, même et surtout pour les insertions manuelles.

L'article explique comment migrer d'un système utilisant GRUB Legacy vers GRUB2, le chargeur d'amorçage moderne. Il détaille les étapes nécessaires, notamment l'installation de GRUB2, la mise à jour du fichier de configuration et l'installation du chargeur d'amorçage sur le MBR. L'auteur met également en garde contre les erreurs courantes et fournit des conseils pour éviter les problèmes lors de la migration.

L'auteur du blog a récemment migré son infrastructure personnelle, composée de quelques machines virtuelles gérées par Ansible, vers un cluster Kubernetes mono-nœud. Il explique que cette transition lui permet de gérer ses applications et leurs dépendances de manière entièrement déclarative, en utilisant des fichiers YAML dans un dépôt Git. Cette approche simplifie la mise à jour et la maintenance des applications, réduisant ainsi le temps et les efforts nécessaires pour gérer son infrastructure. Il mentionne également que Kubernetes offre une meilleure gestion des versions des runtimes et des dépendances, ce qui n'était pas toujours possible avec Ansible. Enfin, il souligne que cette migration a été un succès, lui permettant de gérer ses services de manière plus efficace et automatisée

L'article explique comment migrer des colonnes de type array vers json avec Doctrine, suite à la dépréciation des types array et object dans la version 3 de Doctrine. Il propose une méthode en plusieurs étapes : créer un type Doctrine hybride pour gérer les deux formats, migrer les données sans interrompre le déploiement, et finalement supprimer le type hybride une fois la migration terminée. Le processus permet de migrer les données de manière efficace et sans temps d'arrêt.

Tout est dans le titre

Tout est dans le titre

Tout est dans le titre

Tout est dans le titre - l'auteur migre de Docker vers Kubernetes

Tout est dans le titre

Tout est dans le titre

Suite de https://www.antoinefi.net/index.php/2024/08/22/laboratoire-infra-linux-ha-1/ l'auteur montre la migration de sa base de données vers un hôte dédié. En passant, il montre comment désactiver la télémétrie lors de l'installation de Percona MySQL

Tout est dans le titre

Tout est dans le titre

Tout est dans le titre

Tout est dans le titre

Tout est dans le titre

Tout est dans le titre