Cédrix
1 line
16 KiB
JSON
1 line
16 KiB
JSON
[{"uuid":"6e3e231f-a4a7-4491-b3e6-e6e6e48a362e","slug":"sgbd","title":"SGBD - Système de gestion de base de données","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-10 22:48:50","created_at":"2023-02-10 22:48:50","updated_at":"2023-02-10 22:48:50","tags":[],"plain":"les SGBD connus\nPostgreSQL | PostgreSQL est la base de données à utiliser pour les gros projets. Stable et très puissant, il permet de gérer des Go de données sans problème. | |\n------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\nMySQL | Mysql est l'un des SGBD les plus utilisés au monde. Il est gratuit et très puissant. Il possède la double licence GPL et propriétaire depuis son rachat par Sun Microsystem eux-mêmes racheté par Oracle (concurrent direct de MySQL). Le logiciel reste cependant entièrement gratuit et libre. Il répond à une logique client/serveur , c'est à dire que plusieurs clients (ordinateurs distants) peuvent se connecter sur un seul serveur qui héberge les données. | |\nMariaDB | Le créateur de MySQL a crée MariaDB suite au rachat de MySQL pour continuer le projet en open source. | |\nSQLite | SQLite est une bibliothèque écrite en C . SQLite est parfait pour les petits projets. Sa particularité est d'être intégré directement à un programme et ne répond donc pas à la logique client-serveur. Il est le moteur de base de données le plus distribué au monde puisqu’il est intégré à de nombreux logiciels grand public comme FireFox, Skype, Adobe, etc. Le logiciel pèse moins de 300 ko et peut donc être intégré à des projets tournant sur de petites supports comme les smartphones. Souvent aucune installation n'est nécessaire pour l'utiliser. | |\nOracle | Oracle Database est sous licence propriétaire, c'est à dire payant. Il est souvent utilisé pour les projets à gros budget nécessitant de réaliser des actions complexes. | |\nMicrosoft SQL Server | Produit Microsoft, sous licence propriétaire. Une version \"Express\" est distribuée gratuitement sur Windows et Linux. Avec des performances et caractéristiques moindre que les versions Entreprise. | | Il y a également DB2, mongoDB, Sybase,Firebird, cassandra, MS Access...\nLequel choisir ?\nIl existe toujours des faux débats pour savoir quelle technologie est meilleure que l'autre. Mais souvent, ces débats n'ont aucun sens. On préférera MySQL pour des projet plus modestes où le nombre d'utilisateurs est faible avec un petit volume de données. Sinon, PostGreSQL est une bonne solution car elle est robuste, efficace et reconnu par des professionnels."},{"uuid":"6b99450c-94c3-4c94-afad-64c167c3b834","slug":"35-20200511-installer-sgbd-sur-raspberry-pi","title":"Installer un SGBD sur Raspberry Pi","category":"Podcasts","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-10 22:48:32","created_at":"2023-02-10 22:48:32","updated_at":"2023-02-10 22:48:32","tags":[],"plain":"Je vous raconte mon projet de migration de bases données MySQL que j'avais sur un serveur Fedora vers un Raspberry Pi. Voici un rapide tour des informations que je traite dans cet épisode de podcast Tech. Épisode audio disponible dès le lundi 11 mai 2020.\\\\\n[Épisode disponible sur https://info.mindcast.fr/media/2020-05-1135cedricabonnel-installerunsgbdsurraspberrypi.mp3] Cette page est amenée à évoluer. Vous pouvez réagir à cet épisode\n- SGBD sur Raspberry Pi MariaDB / PostGeSQL\nInformations sur Maria DB\n- Boot d'un Raspberry Pi 4 sur disque dur externe à suivre dans un épisode vidéo\n- Meilleure performance sur Raspberry Pi avec un disque dur externe à suivre dans un épisode vidéo\n- Installer MariaDb client et serveur sur Raspbian 10 (19 Mo - 150 Mo)\nGuide pour Installer MariaDB\n- ARM HF pour Raspberry Pi** Hard Float, processeur ARM v.7 avec instructions 32 bits et virgule flottante. Processeur moins énergivore."},{"uuid":"efe85d09-c167-476a-bda2-ae9aaf36042e","slug":"deplacer-les-fichiers-du-sgbd","title":"Déplacer les fichiers de données du SGBD ?","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-10 22:48:29","created_at":"2023-02-10 22:48:29","updated_at":"2023-02-10 22:48:29","tags":[],"plain":"La restauration consiste à déposer des fichiers de sauvegarde dans un nouveau système, afin de reprendre le travail au moment où la sauvegarde des fichiers a été effectuée. Voilà comment j'ai procédé pour restaurer les fichiers systèmes sans se soucier du format des bases de données (innoDB, MyISAM...).\nIl faut effectuer ces opérations sur un SGBD Maria DB vierge, car cela effacera tout le contenu actuel du SGBD.\n- Arrêt des services :\n sudo systemctl stop mariadb\n- Sauvegarder les fichiers actuels, du SGBD destination :\n sudo tar cvf mysql.tar.gz /var/lib/mysql\n- Noter les user et group utilisés actuellement :\n ls -lha /var/mysql Par défaut c'est mysql:mysql avec les droits 660 pour les fichiers et 700 pour les dossiers\nle dossier racine est 755 pour mysql:mysql\n- Effacer tous les fichiers présents dans le dossier de destination sudo rm -fr /var/lib/mysql/\n-- Copier les anciens fichiers qui se trouvent sur sudo cp -r /mnt/disk18/mysql/* /var/lib/mysql/\n-- changement du owner/group sudo chown -R mysql:mysql /var/lib/mysql\n-- Vérifier le nouvel emplacement à MySQL à partir de son fichier de configuration :\n-- Démarrer le service sudo systemctl start mariadb"},{"uuid":"5a0cced3-40d0-46bf-8501-b533f3c2608e","slug":"reparer-une-instance-uptime-kuma-installee-via-le-script-proxmox","title":"Réparer une instance Uptime Kuma installée via le script Proxmox","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2025-11-26 08:33","created_at":"2025-11-26 08:33:49","updated_at":"2026-05-12 09:16:00","tags":[],"plain":"Méthode basée sur l'installation via le script communautaire :\r\ncommunity-scripts.github.io/ProxmoxVE/scripts?id=uptimekuma\r\n\r\nSi tu utilises Uptime Kuma pour monitorer ton infra, tu finiras tôt ou tard par tomber sur un de ces grands classiques : le service qui refuse de démarrer après une mise à jour, des erreurs SQLite louches dans , ou pire — l'interface qui tourne mais ne remonte plus aucun heartbeat. Dans 90 % des cas, c'est la base SQLite qui a pris cher, souvent à cause d'un arrêt brutal du conteneur LXC ou d'une migration qui s'est mal passée.\r\n\r\nAvant de paniquer et de tout réinstaller, il y a une série d'étapes à dérouler. Je les mets ici dans l'ordre, parce que l'ordre compte : on commence toujours par le moins destructif.\r\n\r\nPourquoi SQLite et pas un vrai SGBD ?\r\n\r\nPetite parenthèse pour les juniors qui se demanderaient. Uptime Kuma embarque SQLite parce que c'est une appli pensée pour être facile à déployer : pas de serveur de base à installer à côté, pas de credentials à gérer, juste un fichier sur le disque. C'est génial pour démarrer, mais ça a un défaut majeur — SQLite n'aime pas du tout être coupé en plein milieu d'une écriture. Si ton LXC tombe pendant que Kuma écrit un heartbeat, tu peux te retrouver avec un fichier corrompu. D'où l'importance de toujours arrêter proprement le service avant de toucher au fichier.\r\n\r\n1. Arrêter le service proprement\r\n\r\n\r\n\r\nC'est la première chose à faire, toujours. Tant que le service tourne, il a un verrou sur et il continue d'y écrire. Tu peux ouvrir le fichier en lecture avec malgré ce verrou, mais dès que tu veux faire un ou un , tu vas soit avoir une erreur , soit — pire — corrompre encore plus la base si tu forces.\r\n\r\nVérifie que c'est bien arrêté avant de continuer :\r\n\r\n\r\n\r\nTu dois voir . Pas , pas , pas avec un process encore en l'air.\r\n\r\n2. Aller dans le dossier de l'app\r\n\r\nLe script communautaire installe Kuma dans :\r\n\r\n\r\n\r\nDans ce dossier, ce qui nous intéresse c'est le sous-dossier . C'est là que vit tout ce qui compte : le fichier (la base), les uploads, et quelques fichiers de config. Le reste (, , etc.) c'est le code de l'application — tu peux le casser, un ou une réinstallation le remettra en place. Mais , si tu le perds, tu perds toute ta config de monitoring.\r\n\r\n3. Sauvegarder avant de toucher à quoi que ce soit\r\n\r\nRègle d'or de l'ops : on ne touche jamais à une base de données sans avoir une copie au chaud. Jamais.\r\n\r\n\r\n\r\nLe te génère un suffixe du genre . Comme ça si tu fais plusieurs interventions dans la même semaine, tu sais laquelle date de quand, et tu ne risques pas d'écraser une sauvegarde par une autre.\r\n\r\nCette copie embarque :\r\nla base elle-même\r\nles fichiers WAL (, ) si SQLite est en mode Write-Ahead Logging — c'est important de les prendre avec, sinon ta sauvegarde est incomplète\r\nles uploads et certificats si tu en as\r\n\r\nSi tu sautes cette étape et que tu te plantes à l'étape 5 ou 6, tu n'auras aucun moyen de revenir en arrière. Sérieusement, fais-le.\r\n\r\n4. Vérifier l'intégrité de la base\r\n\r\n\r\n\r\n, c'est la commande de diagnostic native de SQLite. Elle parcourt toute la base, vérifie que les index pointent bien sur les bonnes lignes, que les pages ne sont pas corrompues, que les contraintes sont respectées. Deux issues possibles :\r\n* : la base est saine sur le plan structurel. Si Kuma ne démarre toujours pas, le problème vient probablement d'une migration coincée (voir étape 5) ou du code de l'app, pas du fichier.\r\nUne liste d'erreurs : il y a de la corruption. Selon ce qui est touché, on passera à l'étape 5 ou 6.\r\n\r\nPour les juniors qui découvrent SQLite : , c'est le mot-clé que SQLite utilise pour les commandes qui ne sont pas du SQL standard — c'est spécifique à SQLite, tu ne le verras pas dans PostgreSQL ou MySQL.\r\n\r\n5. Supprimer un paramètre de migration corrompu\r\n\r\nSur certaines versions de Kuma (notamment autour des montées de version qui touchent à l'agrégation des heartbeats), il y a un bug connu : l'entrée dans la table se retrouve dans un état incohérent, et le service refuse de démarrer parce qu'il pense être au milieu d'une migration qui n'avance plus.\r\n\r\nLa fix :\r\n\r\n\r\n\r\nCe qu'on fait, c'est qu'on dit à Kuma : \"oublie où tu en étais, repars de zéro sur ce point\". Au redémarrage, il va recréer la clé proprement et relancer la migration depuis le début. C'est non destructif pour tes données de monitoring — on ne touche qu'à un drapeau d'état interne.\r\n\r\nSi ce n'est pas ton problème (clé absente ou suppression sans effet), passe à la suite.\r\n\r\n6. Solution radicale : vider la table \r\n\r\nSi la corruption est concentrée sur l'historique de monitoring (et c'est souvent le cas, parce que c'est la table où Kuma écrit le plus souvent — un INSERT toutes les 20-60 secondes par sonde, ça finit par faire du volume), tu peux la vider :\r\n\r\n\r\n\r\nÀ lire attentivement : cette commande supprime tout l'historique des sondes. Tu perds les graphes de uptime, les SLA calculés sur les 30/90/365 derniers jours, tout. En revanche :\r\ntes sondes sont conservées (table )\r\ntes utilisateurs aussi (table )\r\ntes notifications également (table )\r\nta config générale est intacte (table )\r\n\r\nC'est à utiliser uniquement quand :\r\npointe vers des problèmes sur ou ses index\r\nKuma refuse de démarrer et l'étape 5 n'a rien donné\r\nou plus simplement, ta base a tellement grossi que Kuma rame et que tu acceptes de perdre l'historique pour repartir propre\r\n\r\nTant qu'à faire, profites-en pour faire un derrière, qui va vraiment libérer l'espace disque (un seul ne récupère pas la place sur le disque, il marque juste les pages comme libres pour réutilisation) :\r\n\r\n\r\n\r\n7. Redémarrer le service\r\n\r\n\r\n\r\nEt vérifie qu'il a bien démarré :\r\n\r\n\r\n\r\nTu dois voir . Si tu vois ou si le service redémarre en boucle, ne le laisse pas dans cet état — passe directement à l'étape 8 pour comprendre pourquoi.\r\n\r\n8. Lire les logs\r\n\r\n\r\n\r\nLe cible le service, le fait du (équivalent de ) — les nouvelles lignes s'affichent en temps réel. Laisse tourner pendant deux ou trois minutes, le temps que Kuma rejoue ses migrations, recharge ses sondes, et envoie les premiers heartbeats.\r\n\r\nCe qu'il faut chercher dans les logs :\r\nerreurs SQLite : , , — ça veut dire que t'as encore un problème de fichier, voire de permissions\r\nmigrations bloquées : des messages du genre qui ne sont jamais suivis d'un \r\npermissions : , — typiquement après une intervention faite en root sur des fichiers qui doivent appartenir à un autre utilisateur. Vérifie avec que les fichiers sont bien possédés par l'user qui fait tourner le service\r\nmodules Node manquants : — ça arrive après une mise à jour qui s'est mal passée. La fix, c'est généralement de relancer dans \r\nport déjà utilisé : — tu as un autre process qui squatte le port 3001 (ou celui que tu as configuré)\r\n\r\nPour sortir du , c'est .\r\n\r\nEt après ?\r\n\r\nUne fois que Kuma tourne propre, prends cinq minutes pour mettre en place ce qui t'aurait évité d'arriver ici :\r\n\r\n1. Une sauvegarde régulière de . Un simple cron qui fait du dossier vers un autre serveur, ça suffit largement pour un Kuma perso. Pense à arrêter le service avant le tar, ou utilise qui fait un snapshot cohérent sans devoir couper Kuma.\r\n2. Un monitoring du monitoring. Oui, c'est méta. Mais si Kuma tombe, c'est lui qui t'aurait alerté de la chute de tes autres services — donc personne ne te prévient. Un check externe (UptimeRobot gratuit, healthchecks.io, ou un autre Kuma sur une autre machine) qui ping ton instance, c'est cinq minutes à mettre en place.\r\n3. Garder ta sauvegarde au moins une semaine** avant de la supprimer. Au cas où un effet de bord apparaîtrait quelques jours plus tard.\r\n\r\nEt voilà. Avec ces huit étapes, tu couvres 95 % des cas de Kuma cassé. Pour les 5 % restants — typiquement quand le LXC lui-même a un souci de filesystem — c'est une autre histoire, et il faudra sortir l'artillerie côté Proxmox."},{"uuid":"a15c027a-68ed-4a51-9aa6-ac46764f0dad","slug":"migration-d-un-sgbd-postgres","title":"Migration PostgreSQL","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-01-09 08:05:08","created_at":"2025-01-09 08:05:08","updated_at":"2025-01-09 08:05:08","tags":[],"plain":"Dans ce guide, je vous explique les étapes que j'ai appliquée récemment pour migrer une base de données PostgreSQL d'un ancien système à une nouvelle infrastructure. Il couvre la mise à niveau du système, la sauvegarde des bases, leur transfert et restauration, ainsi que la réinitialisation du mot de passe administrateur. upgrade de l'ancien SGBD\nPour garantir une migration fluide, commencez par mettre à jour le système et ses packages. 🖥️ Commandes à effectuer dans le terminal en tant que root ! ℹ️ La version actuelle de PostGres est à 17.1.2. Sauvegarde des anciennes bases\nUne sauvegarde complète de vos bases et de vos rôles est indispensable avant toute migration. 🖥️ Commandes à effectuer dans le terminal avec le user postgres : Sauvegarde des bases de données : Sauvegarde des rôles uniquement : Les fichiers sauvegarde.sql et roles.sql contiennent toutes les informations nécessaires pour la restauration. Transfert vers la nouvelle machine\nTransférez les fichiers sauvegardés depuis l'ancienne machine vers la nouvelle. Copie des fichiers et de l'ancienne vers la nouvelle machine. Utilisation de . Restauration\nUne fois les fichiers copiés, effectuez leur restauration sur la nouvelle machine. 🖥️ Commandes à effectuer dans le terminal avec l'utilisateur postgres Importation des rôles : Restauration des bases de données Réinitialiser le mot de passe de PostGres\nPour des raisons de sécurité, réinitialisez le mot de passe de l'utilisateur postgres. 🖥️ Commandes à effectuer dans le terminal en tant que root :"}] |