De manière générale, les outils "HTML to PDF" sous licence libre sont assez limités (librairies comme TCPDF, etc.), ou pénibles à installer et gourmands en mémoire (basés sur Chrome headless). Pour cette raison, mon entreprise utilise PrinceXML (via DocRaptor, qui fournit Prince en SaaS), qui est un logiciel propriétaire offrant beaucoup de fonctionnalités.
Après, oui PHP s'est complexifié, dans le sens où il offre maintenant des fonctionnalités supplémentaires et des facilités d'écriture. Mais beaucoup d'évolutions sont à destination des développeurs de frameworks et ne sont pas forcément destinées aux développeurs applicatifs. De manière générale, tu utilises ce que tu veux utiliser… la limite étant l'utilisation de code externe.
La courbe d'apprentissage de PHP reste assez douce quand on vient de langages comme le C ou la Java. Comme c'est un langage qui n'a pas grand-chose à envier aux autres sur le plan des fonctionnalités et des performances, si tu as déjà les bases ça peut valoir la peine de te tenir à jour des évolutions du langage de temps en temps. Ce sera beaucoup moins violent que de se former à un autre langage moderne.
Là où je suis d'accord, c'est que par rapport au C, on est sur un rythme très différent. Mais es-tu au courant des nouveautés des normes C11 et C18 ? J'avoue que même si je continue à coder en C (rarement mais ça m'arrive, la sensation de toute puissance quand on sait ce qu'on fait avec la mémoire est assez géniale), je suis resté au C99… si j'ai besoin de “plus” (plus de fonctionnalités ou plus de simplicité), je vais vite passer au PHP.
Question de point de vue. Il y a tellement de logiciels écrits en C qui te prouvent le contraire…
Encore une fois, si tu sais ce que tu fais et que tu utilises les bons outils, le C est à la fois simple et puissant.
Mais bon, on s'éloigne du sujet (et c'est de la bonne matière à troll, tout ça).
Ce retour d'expérience est vraiment très intéressant, aussi bien pour les aspects techniques qu'organisationnels.
J'ai juste relevé une petite erreur, induite je pense par l'excès d'enthousiasme : le C++ a quarante ans et se compile toujours dans le même esprit que le C qui a lui soixante ans
Autant on peut arrondir à 40 ans pour le C++ (37 ans en fait), autant c'est vieillir le C d'une quinzaine d'années (créé en 1972 mais stabilisé vers 1978).
Et je pense qu'on ne compilait pas dans les années 70 de la même manière que maintenant (make est apparu en 1977, et j'imagine que ça a pris du temps avant qu'il ne se répande).
Encore merci pour l'article. Personnellement, je préfère le C quand je veux m'éloigner des langages interprétés (et je ne suis pas le seul, comme je l'écrivais sur mon blog il y a quelques années). La simplicité extrême du langage, la sensation de puissance… Comme le dit Ben Klemens (auteur du livre 21st Century C), le C c'est le langage punk :)
Non, je n'en vois pas trop l'utilité pour l'instant, le temps de compilation par tcc étant négligeable. Ou alors plus tard : on pourrait l'utiliser par défaut si aucun compilateur n'a été trouvé (par exemple).
Oui, utiliser tcc à la place de gcc permettrait déjà de voir si le code C produit est bien compatible (je ne sais pas si vous utilisez des spécificités de la norme C11 ; il me semble que tcc n'est compatible qu'avec la norme C99, qui est quand même 12 ans plus vieille). Il faudrait aussi regarder si tcc supporte toutes les plateformes que Gambas supporte.
Et je serais aussi curieux de voir le résultat en terme de performance (sachant que tcc sera plus rapide à compiler, mais produira du code moins rapide ; c'est vraiment ce qui se rapproche le plus d'une compilation JIT).
Est-ce que le fait de pouvoir choisir le compilateur est vraiment primordial ? (c'est une vraie question)
Je trouve que c'est plus "propre" d'avoir un compilateur qui contienne tout ce dont il a besoin, plutôt que de passer par des programmes externe. On pourrait dire qu'utiliser une librairie externe versus un programme externe ne change pas grand-chose ; mais très concrètement je pense qu'une installation de Gambas peut embarquer des librairies (c'est assez commun), mais plus difficilement embarquer gcc ou clang.
Ce compilateur traduit le « bytecode » Gambas en langage C pendant l’exécution, et utilise ensuite le compilateur du système (gcc ou clang) pour obtenir le code machine final.
Plutôt que d'appeler un compilateur externe, est-ce que vous avez envisagé d'utiliser la bibliothèque du compilateur TinyCC (libtcc) ? Il produit du code moins optimisé que GCC/LLVM, mais il compile beaucoup plus vite, ce qui est parfait pour une compilation JIT. Et ça évite une dépendance avec un programme externe.
Peut-être que Gambas a besoin de produire du code C++ et non pas du code C (notamment pour Qt) ? Si c'est le cas, je comprendrais que TinyCC ne soit pas utilisable.
Suite aux demandes et remarques en commentaire, Arkiv supporte maintenant la sauvegarde binaire de bases de données MySQL par xtrabackup. Il est possible de configurer des sauvegardes complètes et des sauvegardes incrémentales.
N'hésitez pas à tester et à me faire des retours via la buglist ou par email.
PS : Plus anecdotique, j'ai aussi ajouté le support de syslog.
Le --single-transaction, ça fonctionne uniquement lorsque tu est en full-InnoDB. Sinon, ton dump ne va pas être consistent.
Oui, bien sûr. Tu as encore des tables en MyISAM, toi ? Quel intérêt ?
Bon, je vais regarder tout ça de près. Merci à tous pour vos conseils et liens.
Comme je l'ai déjà dit, le but reste quand même de garder un code simple et clair, pas de faire un machine énorme qui répond à tous les besoins. L'utilisation de mysqldump est facile (je pense que toutes les distribs l'installent dès qu'on installe un client MySQL), c'est pour ça que je l'ai ajoutée (et aussi parce que − comme on me l'a fait remarquer − Arkiv est en concurrence avec Backup-Manager, qui gère mysqldump).
Mais je comprends bien l'intérêt :)
Petites question à mon tour :
1. Comment faites-vous vos sauvegardes actuellement ?
2. Est-ce que Arkiv vous serait utile, et n'y a-t-il vraiment que la sauvegarde par xtrabackup qui manque ? (et dans ce cas, pourquoi ne pas commencer par lancer xtrabackup avant Arkiv dans la crontab ?)
Non, justement. Comme je l'ai indiqué dans un précédent commentaire, j'ai écrit un article de blog sur la question. Il est possible de ne pas verrouiller les tables, et de faire le dump dans une transaction pour être sûr de ne pas récupérer des données qui ont changé pendant la durée du dump. C'est d'ailleurs expliqué dans le lien que tu as fourni.
Et pour ce qui est des caches MySQL qui se retrouvent à être utilisés pour mysqldump au lieu d'être remplis de données utiles pour les traitements "normaux" de la base, la solution est de mettre en place une réplication maître-esclave et de faire les sauvegardes sur l'esclave.
Mais je comprends aussi que s'il existe un outil plus performant, ce serait idiot de ne pas le supporter :)
Toutefois ce serait une erreur de ne pas supporter mysqldump, qui a l'avantage d'être quasi-toujours là. Et accessoirement, puisque quelqu'un comparaît avec Backup-Manager, il faut bien dire que lui aussi passe par mysqldump (oui, je sais que backup-manager peut sauvegarder les données de n'importe quel programme en passant par un “pipe”, mais ce n'est plus du «out-of-the-box»).
Et pour être complet :
- Backup-manager peut sauvegarder des fichiers de manière incrémentale, avec que Arkiv fait toujours des sauvegardes complètes. [1]
- Backup-manager peut sauvegarder spécifiquement les données de serveurs Subversion ou celles de programmes qui sont "pipés".
- Backup-manager est capable d'envoyer les sauvegardes par SCP, FTP ou rsync, et peut aussi graver des CD/DVD. Arkiv se contente d'Amazon S3 et Amazon Glacier.
- Backup-manager peut encrypter les données avec GPG, alors que Arkiv utilise OpenSSL.
[1] : C'est un choix de ma part. Je préfère avoir des sauvegardes complètes car elles sont plus faciles à restaurer (une seule archive à déployer, plutôt que de déployer la dernière archive complète plus toutes les archives incrémentales sauvegardées depuis). Ça peut évidemment faire stocker plus de données, mais avec une gestion fine des purges − comme le permet Skriv − je pense qu'on s'y retrouve largement.
Je te pose la même question qu'aux autres qui m'ont fait une demande similaire : Est-ce que tu aurais des liens qui documenteraient les limitations de mysqldump ? Ça m'intéresse évidemment.
Le code est découpé en fonctions et assez bien commenté, donc il est plutôt facile à maintenir. Je n'ai pas séparé le script en deux pour une bonne raison : En shell, il est impossible de savoir de manière sûre à 100% le chemin du script qui s'exécute (cf. http://mywiki.wooledge.org/BashFAQ/028). Du coup, il devient très compliqué d'inclure des fichiers sans imposer l'installation du programme dans une arborescence fixe (solution utilisée par backup-manager, par exemple). Je tiens à ce que le programme soit utilisable par n'importe quel utilisateur sans qu'il n'ait été d'abord installé par le root. Et il y a certaines parties du code qui sont mutualisées (notamment la gestion du formatage ANSI).
Pour les défaut de mysqldump, est-ce que tu as des liens à ce sujet ? Comme je l'ai déjà dit dans un commentaire précédent, je n'ai jamais été face à une volumétrie telle que cet outil pouvait poser problème (et pourtant, j'ai fait pas mal de sauvegardes en production sur des bases assez conséquentes ces 15 dernières années).
Comme je le dis sur mon article de blog (en lien dans la dépêche), j'ai utilisé backup-manager pendant les 10 dernières années grosso modo.
Ce que Arkiv fait et que backup-manager ne fait pas :
- Possibilité de choisir la fréquence de sauvegarde, que ce soit plusieurs fois par jour (jusqu'à toutes les heures) ou pas tous les jours, alors que backup-manager est fait pour sauvegarder une fois par jour uniquement.
- Peut archiver les données à long-terme sur Amazon Glacier (en plus de les archiver à moyen-terme sur Amazon S3, comme backup-manager).
- Gère des politiques de purge complexes (cf. l'exemple donné dans la dépêche), alors que backup-manager efface tous les fichiers après un certain délai (et que en local, pas sur Amazon S3).
- Aide à la création du fichier de configuration.
- Fichiers de logs plus faciles à lire (c'est subjectif, je sais, mais un effort a été fait là-dessus).
Je ne sais pas pour les toutes dernières version de backup-manager, mais celle que j'utilisais n'était pas compatible avec les datacenters Amazon les plus récents (celui de Londres par exemple), qui ne sont pas compatibles avec les anciennes versions de l'API.
Je ne sais pas ce que tu veux dire quand tu parles de contrepartie. Il n'y a pas de limite au volume. C'est sûr que si tu as de grosses bases de données et/ou des fichiers volumineux, la sauvegarde risque de prendre du temps. Mais c'est difficile de faire autrement. Comme il est possible d'exécuter plusieurs instances d'Arkiv en parallèle, avec des fichiers de configuration différent, on peut imaginer faire des sauvegardes séparées pour que les données les plus légères soient archivées plus fréquemment.
Le dump de la base se fait dans une transaction, donc il n'y a pas besoin de mettre quoi que ce soit en pause à la condition que les tables soient toutes en InnoDB. La chose est détaillée dans un article de mon blog.
Ensuite, il est possible de mettre en place une stratégie de réplication maître-esclave, pour que la sauvegarde des bases se fasse sur un esclave (afin de ne pas impacter le serveur maître, que ce soit en consommation CPU ou mémoire). Il est aussi possible d'utiliser les logs binaires ; c'est alors une sauvegarde classique de fichier. Mais il vaut quand même mieux avoir un dump complet de temps en temps.
Pour la question du partitionnement des tables, c'est quelque chose que je n'ai jamais vu mis en œuvre uniquement pour la sauvegarde (je l'ai déjà vu pour faire du sharding par exemple). Sur quel genre de volumétrie as-tu eu besoin de faire ça ?
Les seules limites pour le moment concernent Amazon :
- Les fichiers peuvent faire jusqu'à 5 TO sur Amazon S3 (source)
- Les fichiers peuvent faire jusqu'à 40 TO sur Amazon Glacier (source)
Je ferai peut-être une évolution pour découper les fichiers dont la taille est supérieure à ces limites. Je n'en ai personnellement pas le besoin, donc si ça peut être utile à quelqu'un, ce serait bien de me faire signe :)
Effectivement, le mot «encrypter» existe en français, mais pas «encryption»…
On reparlera de LibreSSL quand ce sera intégré dans les dépôts de toutes les principales distributions, hein. En attendant, l'utilisation d'OpenSSL ne pose strictement aucun problème. On peut faire plus simple, c'est vrai, mais dans le cadre qui concerne Arkiv (encrypter des données en utilisant une clé symétrique) il n'y a rien de compliqué, et c'est bien documenté dans le README.
La question aurait plutôt pu être pourquoi OpenSSL plutôt que OpenPGP/GnuPG. La réponse : parce que je connais mieux.
Je viens d'ajouter une fonctionnalité d'encryption. Les données peuvent maintenant être cryptées en utilisant OpenSSL (algorithme AES 256 bits), aussi bien pour les fichiers stockés en local que pour ceux enregistrés sur Amazon S3 et Amazon Glacier.
Il est possible d'utiliser une clé générée préalablement ou de fournir une passphrase.
Dans l'appel à commentaires de l'AFNOR, il est possible de faire des suggestions. Voilà ce que j'ai écrit au sujet de leur proposition de nouveau clavier Azerty :
Garder les caractères ç, ù, $, " accessibles sans combinaison de touches.
Rendre les caractères µ, | accessibles via une combinaison de 3 touches.
Le caractère arobase (@) devrait être accessible sans combinaison de touche, ou au pire en appuyant sur la touche Majuscule (et non pas AltGr).
Le caractère multiplication (×) devrait être proche du caractère division (÷). Les deux devraient être sur la même touche (l'un accessible avec la combinaison AltGr et l'autre avec Maj+AlGr) ou sur deux touches adjacentes.
Pour faciliter le développement informatique, il faudrait garder les caractères {, }, [, ] accessibles via une combinaison de 2 touches, mais en les regroupant sur le clavier ({ et } l'un à-côté de l'autre ; [ et ] l'un à-côté de l'autre).
Non. Toujours dans l'optique de «faisons simple et éprouvé», il est plus facile d'administrer le cluster quand on peut voir les fichiers de méta-données en faisant un simple 'ls' ou 'tree', et quand on peut voir les méta-données en faisant un simple 'more'.
Oui, c'était juste une digression, pour partager mes réflexions avec vous ;-)
Le but premier de FineFS est (et restera) d'accéder rapidement à des fichiers statiques.
Il n'empêche que les méta-données sont librement utilisables par les applications. Notre couche de gestion des médias (qui devrait bientôt passer sous licence libre) utilise les méta-données pour stocker les informations de type ACL (accès publique ou privé), les durées de mise en cache (côté client) et les types MIME. Mais les applications peuvent ajouter les métas dont elles ont besoin.
Alors oui, un système de gestion de données non relationnelles peut apporter des performances intéressantes. Mais ce n'est pas une orientation courante dans le développement d'applis web.
Bref, on est en train de s'éloigner du sujet, là...
Très bon exemple, qui correspond à la partie sur laquelle je suis en train de travailler en ce moment ! ;-)
Tel que le code existe pour le moment (version 0.3.0, donc instable), le serveur 2 récupérera le fichier en cours de modification (donc incomplet). Pour reprendre un exemple que j'ai déjà cité, c'est exactement ce qui se passera si tu as un programme qui lit un fichier sur un filesystem Ext3 local, alors qu'un autre programme est en train d'écrire dedans. C'est au niveau applicatif qu'il faut gérer cette possibilité (lock sur le fichier, sémaphore, ...).
Mais la version stable de FineFS permettra d'avoir toujours un état cohérent. Dans ton exemple, le serveur 2 récupérera alors la première version du fichier. La nouvelle version ne sera disponible qu'une fois l'écriture terminée.
Non, c'est l'inverse : Si on ajoute la gestion de 2 types de machines (les noeuds globaux et les noeuds avec cache), cela va augmenter la complexité du software (des cas supplémentaires à gérer) pour diminuer les prérequis sur le hardware (pas besoin que toutes les machines aient des disques assez gros pour contenir toutes les données du cluster).
C'est une question complètement décorrélée de la problématique de l'ajout/suppression de machines à chaud, qui reste compliquée qu'il y ait un seul type de noeuds ou deux.
Pour le reste, on a sérieusement pensé à memcache (on l'utilise déjà pour le cache des applis web). Mais au final, c'était une fausse bonne idée : la récupération d'un fichier de moins de 200 octets n'est pas drastiquement plus rapide via memcache qu'en le lisant sur le disque. Il y a des couches logicielles en plus, des ouvertures de sockets, des copies de données... sans parler du fait de devoir gérer les éventuels problèmes de connexion sinon on risque d'avoir tout le système qui tombe (ou simplement qui ralentit) parce que memcache est en rade.
Même si ça s'éloigne des buts de FineFS, il serait intéressant (d'un point de vue théorique) de stocker les méta-données dans une base de données (je donnais l'exemple de SQLite, dont la philosophie s'accorde bien à celle de FineFS). Ainsi, il serait possible de rechercher des fichiers à partir de leurs méta-données, et non pas simplement récupérer des méta-données à partir du nom de fichier.
Cela permettrait d'avoir un système de données non relationnel (cf. Dynamo d'Amazon ou Cassandra de Facebook) qui resterait très performant même sur un très grand nombre de serveurs. Bon, je reste quand même persuadé que sur une architecture classique cela n'a pas un grand intérêt par rapport à une base de données traditionnelle (toutes les applis web utilisent un MySQL/Postgresql/Oracle quelque part)...
L'intérêt du cache serait de ne pas obliger toutes les machines du cluster à stocker l'intégralité des données. Ainsi, on pourrait imaginer un cluster où certaines machines ont de très gros disques et stockent toutes les données, pendant que les autres machines - qui ont des disques de taille plus raisonnable - stockent en local les fichiers les plus utilisés.
C'est assez évident pour une infrastructure dans laquelle les serveurs frontaux (qui ont besoin des fichiers) ont rarement des disques de plusieurs téra-octets, alors que l'ensemble du cluster est susceptible de stocker des téras au final. C'est plus efficace, toujours dans l'optique de lire en local les fichiers dont on va avoir besoin le plus souvent.
Maintenant, je suis d'accord que ça va complexifier le code de FineFS. Mais c'est moins complexe à gérer qu'un système où les fichiers ne sont répliqués que sur certaines machines (ta proposition précédente).
Donc, on codera sûrement un jour ce système de cache, mais en séparant intelligemment le code, pour ne pas charger la partie qui gère le cache si on n'en a pas besoin.
On ne va pas gérer un cache RAM. Pour commencer, FineFS est sans état. Même le démon n'est pas chargé en mémoire de manière continuelle (il est lancé par xinetd). Ensuite, ça complexifierait le code inutilement ; même le jour où on voudra stocker les méta-données dans une base de données, on le fera sûrement en utilisant SQLite plutôt qu'en gardant les infos en RAM.
Parce que garder un cache en RAM, c'est plus facile à dire qu'à faire de manière stable et efficace. Il faut mettre en place de la communication inter-processus, avec de la mémoire partagée ou un démon local sur lequel il faut se connecter (et hop, encore une ouverture de socket en plus !). Non, le gain est trop faible et hypothétique pour se lancer là-dedans.
# Par rapport à PrinceXML ?
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Des nouvelles de WeasyPrint, ou comment développer du libre à (presque) plein temps. Évalué à 2.
Merci pour ce témoignage intéressant.
De manière générale, les outils "HTML to PDF" sous licence libre sont assez limités (librairies comme TCPDF, etc.), ou pénibles à installer et gourmands en mémoire (basés sur Chrome headless). Pour cette raison, mon entreprise utilise PrinceXML (via DocRaptor, qui fournit Prince en SaaS), qui est un logiciel propriétaire offrant beaucoup de fonctionnalités.
Comment vous situez-vous par rapport à Prince ?
[^] # Re: re: La version 8.1 de PHP et création de la fondation PHP
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche La version 8.1 de PHP et création de la fondation PHP. Évalué à 4.
Pour avoir un rappel des évolutions de PHP depuis PHP 7, je t'invite à lire l'article de blog que j'avais écrit sur le sujet : https://www.geek-directeur-technique.com/2021/10/17/de-php-7-a-php-8-retour-sur-cinq-ans-dinnovation
Après, oui PHP s'est complexifié, dans le sens où il offre maintenant des fonctionnalités supplémentaires et des facilités d'écriture. Mais beaucoup d'évolutions sont à destination des développeurs de frameworks et ne sont pas forcément destinées aux développeurs applicatifs. De manière générale, tu utilises ce que tu veux utiliser… la limite étant l'utilisation de code externe.
La courbe d'apprentissage de PHP reste assez douce quand on vient de langages comme le C ou la Java. Comme c'est un langage qui n'a pas grand-chose à envier aux autres sur le plan des fonctionnalités et des performances, si tu as déjà les bases ça peut valoir la peine de te tenir à jour des évolutions du langage de temps en temps. Ce sera beaucoup moins violent que de se former à un autre langage moderne.
Là où je suis d'accord, c'est que par rapport au C, on est sur un rythme très différent. Mais es-tu au courant des nouveautés des normes C11 et C18 ? J'avoue que même si je continue à coder en C (rarement mais ça m'arrive, la sensation de toute puissance quand on sait ce qu'on fait avec la mémoire est assez géniale), je suis resté au C99… si j'ai besoin de “plus” (plus de fonctionnalités ou plus de simplicité), je vais vite passer au PHP.
[^] # Re: Petite erreur
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 5.
Question de point de vue. Il y a tellement de logiciels écrits en C qui te prouvent le contraire…
Encore une fois, si tu sais ce que tu fais et que tu utilises les bons outils, le C est à la fois simple et puissant.
Mais bon, on s'éloigne du sujet (et c'est de la bonne matière à troll, tout ça).
# Petite erreur
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 4.
Ce retour d'expérience est vraiment très intéressant, aussi bien pour les aspects techniques qu'organisationnels.
J'ai juste relevé une petite erreur, induite je pense par l'excès d'enthousiasme :
le C++ a quarante ans et se compile toujours dans le même esprit que le C qui a lui soixante ans
Autant on peut arrondir à 40 ans pour le C++ (37 ans en fait), autant c'est vieillir le C d'une quinzaine d'années (créé en 1972 mais stabilisé vers 1978).
Et je pense qu'on ne compilait pas dans les années 70 de la même manière que maintenant (make est apparu en 1977, et j'imagine que ça a pris du temps avant qu'il ne se répande).
Encore merci pour l'article. Personnellement, je préfère le C quand je veux m'éloigner des langages interprétés (et je ne suis pas le seul, comme je l'écrivais sur mon blog il y a quelques années). La simplicité extrême du langage, la sensation de puissance… Comme le dit Ben Klemens (auteur du livre 21st Century C), le C c'est le langage punk :)
[^] # Re: Concernant le compilateur JIT
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 1.
Effectivement, c'est un bon cas d'usage.
[^] # Re: Concernant le compilateur JIT
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 1.
Donc tu as testé, le code C produit est bien du C99 compatible avec TCC ? Cool.
Pas de plan d'utiliser la librairie alors ?
[^] # Re: Concernant le compilateur JIT
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 2.
Oui, utiliser tcc à la place de gcc permettrait déjà de voir si le code C produit est bien compatible (je ne sais pas si vous utilisez des spécificités de la norme C11 ; il me semble que tcc n'est compatible qu'avec la norme C99, qui est quand même 12 ans plus vieille). Il faudrait aussi regarder si tcc supporte toutes les plateformes que Gambas supporte.
Et je serais aussi curieux de voir le résultat en terme de performance (sachant que tcc sera plus rapide à compiler, mais produira du code moins rapide ; c'est vraiment ce qui se rapproche le plus d'une compilation JIT).
Est-ce que le fait de pouvoir choisir le compilateur est vraiment primordial ? (c'est une vraie question)
Je trouve que c'est plus "propre" d'avoir un compilateur qui contienne tout ce dont il a besoin, plutôt que de passer par des programmes externe. On pourrait dire qu'utiliser une librairie externe versus un programme externe ne change pas grand-chose ; mais très concrètement je pense qu'une installation de Gambas peut embarquer des librairies (c'est assez commun), mais plus difficilement embarquer gcc ou clang.
# Concernant le compilateur JIT
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 4.
Dans la dépêche il est écrit :
Plutôt que d'appeler un compilateur externe, est-ce que vous avez envisagé d'utiliser la bibliothèque du compilateur TinyCC (libtcc) ? Il produit du code moins optimisé que GCC/LLVM, mais il compile beaucoup plus vite, ce qui est parfait pour une compilation JIT. Et ça évite une dépendance avec un programme externe.
Peut-être que Gambas a besoin de produire du code C++ et non pas du code C (notamment pour Qt) ? Si c'est le cas, je comprendrais que TinyCC ne soit pas utilisable.
# Support de xtrabackup
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 2.
Suite aux demandes et remarques en commentaire, Arkiv supporte maintenant la sauvegarde binaire de bases de données MySQL par xtrabackup. Il est possible de configurer des sauvegardes complètes et des sauvegardes incrémentales.
N'hésitez pas à tester et à me faire des retours via la buglist ou par email.
PS : Plus anecdotique, j'ai aussi ajouté le support de syslog.
[^] # Re: Petite suggestion
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 1.
Oui, bien sûr. Tu as encore des tables en MyISAM, toi ? Quel intérêt ?
Bon, je vais regarder tout ça de près. Merci à tous pour vos conseils et liens.
Comme je l'ai déjà dit, le but reste quand même de garder un code simple et clair, pas de faire un machine énorme qui répond à tous les besoins. L'utilisation de mysqldump est facile (je pense que toutes les distribs l'installent dès qu'on installe un client MySQL), c'est pour ça que je l'ai ajoutée (et aussi parce que − comme on me l'a fait remarquer − Arkiv est en concurrence avec Backup-Manager, qui gère mysqldump).
Mais je comprends bien l'intérêt :)
Petites question à mon tour :
1. Comment faites-vous vos sauvegardes actuellement ?
2. Est-ce que Arkiv vous serait utile, et n'y a-t-il vraiment que la sauvegarde par xtrabackup qui manque ? (et dans ce cas, pourquoi ne pas commencer par lancer xtrabackup avant Arkiv dans la crontab ?)
Merci
[^] # Re: Petite suggestion
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 1.
Non, justement. Comme je l'ai indiqué dans un précédent commentaire, j'ai écrit un article de blog sur la question. Il est possible de ne pas verrouiller les tables, et de faire le dump dans une transaction pour être sûr de ne pas récupérer des données qui ont changé pendant la durée du dump. C'est d'ailleurs expliqué dans le lien que tu as fourni.
Et pour ce qui est des caches MySQL qui se retrouvent à être utilisés pour mysqldump au lieu d'être remplis de données utiles pour les traitements "normaux" de la base, la solution est de mettre en place une réplication maître-esclave et de faire les sauvegardes sur l'esclave.
Mais je comprends aussi que s'il existe un outil plus performant, ce serait idiot de ne pas le supporter :)
Toutefois ce serait une erreur de ne pas supporter mysqldump, qui a l'avantage d'être quasi-toujours là. Et accessoirement, puisque quelqu'un comparaît avec Backup-Manager, il faut bien dire que lui aussi passe par mysqldump (oui, je sais que backup-manager peut sauvegarder les données de n'importe quel programme en passant par un “pipe”, mais ce n'est plus du «out-of-the-box»).
[^] # Re: backup-manager
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 3.
Et pour être complet :
- Backup-manager peut sauvegarder des fichiers de manière incrémentale, avec que Arkiv fait toujours des sauvegardes complètes. [1]
- Backup-manager peut sauvegarder spécifiquement les données de serveurs Subversion ou celles de programmes qui sont "pipés".
- Backup-manager est capable d'envoyer les sauvegardes par SCP, FTP ou rsync, et peut aussi graver des CD/DVD. Arkiv se contente d'Amazon S3 et Amazon Glacier.
- Backup-manager peut encrypter les données avec GPG, alors que Arkiv utilise OpenSSL.
[1] : C'est un choix de ma part. Je préfère avoir des sauvegardes complètes car elles sont plus faciles à restaurer (une seule archive à déployer, plutôt que de déployer la dernière archive complète plus toutes les archives incrémentales sauvegardées depuis). Ça peut évidemment faire stocker plus de données, mais avec une gestion fine des purges − comme le permet Skriv − je pense qu'on s'y retrouve largement.
[^] # Re: Petite suggestion
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 1.
C'est envisageable.
Je te pose la même question qu'aux autres qui m'ont fait une demande similaire : Est-ce que tu aurais des liens qui documenteraient les limitations de mysqldump ? Ça m'intéresse évidemment.
[^] # Re: Information sur le volume cible
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 1.
Le code est découpé en fonctions et assez bien commenté, donc il est plutôt facile à maintenir. Je n'ai pas séparé le script en deux pour une bonne raison : En shell, il est impossible de savoir de manière sûre à 100% le chemin du script qui s'exécute (cf. http://mywiki.wooledge.org/BashFAQ/028). Du coup, il devient très compliqué d'inclure des fichiers sans imposer l'installation du programme dans une arborescence fixe (solution utilisée par backup-manager, par exemple). Je tiens à ce que le programme soit utilisable par n'importe quel utilisateur sans qu'il n'ait été d'abord installé par le root. Et il y a certaines parties du code qui sont mutualisées (notamment la gestion du formatage ANSI).
Pour les défaut de mysqldump, est-ce que tu as des liens à ce sujet ? Comme je l'ai déjà dit dans un commentaire précédent, je n'ai jamais été face à une volumétrie telle que cet outil pouvait poser problème (et pourtant, j'ai fait pas mal de sauvegardes en production sur des bases assez conséquentes ces 15 dernières années).
[^] # Re: backup-manager
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 3.
Comme je le dis sur mon article de blog (en lien dans la dépêche), j'ai utilisé backup-manager pendant les 10 dernières années grosso modo.
Ce que Arkiv fait et que backup-manager ne fait pas :
- Possibilité de choisir la fréquence de sauvegarde, que ce soit plusieurs fois par jour (jusqu'à toutes les heures) ou pas tous les jours, alors que backup-manager est fait pour sauvegarder une fois par jour uniquement.
- Peut archiver les données à long-terme sur Amazon Glacier (en plus de les archiver à moyen-terme sur Amazon S3, comme backup-manager).
- Gère des politiques de purge complexes (cf. l'exemple donné dans la dépêche), alors que backup-manager efface tous les fichiers après un certain délai (et que en local, pas sur Amazon S3).
- Aide à la création du fichier de configuration.
- Fichiers de logs plus faciles à lire (c'est subjectif, je sais, mais un effort a été fait là-dessus).
Je ne sais pas pour les toutes dernières version de backup-manager, mais celle que j'utilisais n'était pas compatible avec les datacenters Amazon les plus récents (celui de Londres par exemple), qui ne sont pas compatibles avec les anciennes versions de l'API.
[^] # Re: Information sur le volume cible
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 3.
Merci pour les remerciements :)
Je ne sais pas ce que tu veux dire quand tu parles de contrepartie. Il n'y a pas de limite au volume. C'est sûr que si tu as de grosses bases de données et/ou des fichiers volumineux, la sauvegarde risque de prendre du temps. Mais c'est difficile de faire autrement. Comme il est possible d'exécuter plusieurs instances d'Arkiv en parallèle, avec des fichiers de configuration différent, on peut imaginer faire des sauvegardes séparées pour que les données les plus légères soient archivées plus fréquemment.
Le dump de la base se fait dans une transaction, donc il n'y a pas besoin de mettre quoi que ce soit en pause à la condition que les tables soient toutes en InnoDB. La chose est détaillée dans un article de mon blog.
Ensuite, il est possible de mettre en place une stratégie de réplication maître-esclave, pour que la sauvegarde des bases se fasse sur un esclave (afin de ne pas impacter le serveur maître, que ce soit en consommation CPU ou mémoire). Il est aussi possible d'utiliser les logs binaires ; c'est alors une sauvegarde classique de fichier. Mais il vaut quand même mieux avoir un dump complet de temps en temps.
Pour la question du partitionnement des tables, c'est quelque chose que je n'ai jamais vu mis en œuvre uniquement pour la sauvegarde (je l'ai déjà vu pour faire du sharding par exemple). Sur quel genre de volumétrie as-tu eu besoin de faire ça ?
Les seules limites pour le moment concernent Amazon :
- Les fichiers peuvent faire jusqu'à 5 TO sur Amazon S3 (source)
- Les fichiers peuvent faire jusqu'à 40 TO sur Amazon Glacier (source)
Je ferai peut-être une évolution pour découper les fichiers dont la taille est supérieure à ces limites. Je n'en ai personnellement pas le besoin, donc si ça peut être utile à quelqu'un, ce serait bien de me faire signe :)
[^] # Re: Encryption
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 5.
Effectivement, le mot «encrypter» existe en français, mais pas «encryption»…
On reparlera de LibreSSL quand ce sera intégré dans les dépôts de toutes les principales distributions, hein. En attendant, l'utilisation d'OpenSSL ne pose strictement aucun problème. On peut faire plus simple, c'est vrai, mais dans le cadre qui concerne Arkiv (encrypter des données en utilisant une clé symétrique) il n'y a rien de compliqué, et c'est bien documenté dans le README.
La question aurait plutôt pu être pourquoi OpenSSL plutôt que OpenPGP/GnuPG. La réponse : parce que je connais mieux.
# Encryption
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 5.
Je viens d'ajouter une fonctionnalité d'encryption. Les données peuvent maintenant être cryptées en utilisant OpenSSL (algorithme AES 256 bits), aussi bien pour les fichiers stockés en local que pour ceux enregistrés sur Amazon S3 et Amazon Glacier.
Il est possible d'utiliser une clé générée préalablement ou de fournir une passphrase.
# Commentaire sur le site de l'AFNOR
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Vers une norme AFNOR pour le clavier français. Évalué à 2.
Dans l'appel à commentaires de l'AFNOR, il est possible de faire des suggestions. Voilà ce que j'ai écrit au sujet de leur proposition de nouveau clavier Azerty :
Certains caractères disponibles directement avec les claviers Azerty actuels auraient besoin à l'avenir d'un combinaison de touches : ç, ù, $, "
À l'inverse, d'autres caractères peu utilisés se retrouveraient facilement accessibles : µ, |
Cela amène à déplacer certains caractères de manière non logique. Ainsi, le caractère © (disponible actuellement sous Linux avec AltGr + C) se retrouve associé à la touche X, et le caractère æ (AltGr + A) se retrouverait associé à la touche Z.
Le caractère arobase (@) est très utilisé de nos jours, et ne devrait plus être accessible avec une combinaison de touches.
Garder les caractères ç, ù, $, " accessibles sans combinaison de touches.
Rendre les caractères µ, | accessibles via une combinaison de 3 touches.
Le caractère arobase (@) devrait être accessible sans combinaison de touche, ou au pire en appuyant sur la touche Majuscule (et non pas AltGr).
Le caractère multiplication (×) devrait être proche du caractère division (÷). Les deux devraient être sur la même touche (l'un accessible avec la combinaison AltGr et l'autre avec Maj+AlGr) ou sur deux touches adjacentes.
Pour faciliter le développement informatique, il faudrait garder les caractères {, }, [, ] accessibles via une combinaison de 2 touches, mais en les regroupant sur le clavier ({ et } l'un à-côté de l'autre ; [ et ] l'un à-côté de l'autre).
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
;-)
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
Le but premier de FineFS est (et restera) d'accéder rapidement à des fichiers statiques.
Il n'empêche que les méta-données sont librement utilisables par les applications. Notre couche de gestion des médias (qui devrait bientôt passer sous licence libre) utilise les méta-données pour stocker les informations de type ACL (accès publique ou privé), les durées de mise en cache (côté client) et les types MIME. Mais les applications peuvent ajouter les métas dont elles ont besoin.
Alors oui, un système de gestion de données non relationnelles peut apporter des performances intéressantes. Mais ce n'est pas une orientation courante dans le développement d'applis web.
Bref, on est en train de s'éloigner du sujet, là...
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
Tel que le code existe pour le moment (version 0.3.0, donc instable), le serveur 2 récupérera le fichier en cours de modification (donc incomplet). Pour reprendre un exemple que j'ai déjà cité, c'est exactement ce qui se passera si tu as un programme qui lit un fichier sur un filesystem Ext3 local, alors qu'un autre programme est en train d'écrire dedans. C'est au niveau applicatif qu'il faut gérer cette possibilité (lock sur le fichier, sémaphore, ...).
Mais la version stable de FineFS permettra d'avoir toujours un état cohérent. Dans ton exemple, le serveur 2 récupérera alors la première version du fichier. La nouvelle version ne sera disponible qu'une fois l'écriture terminée.
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
C'est une question complètement décorrélée de la problématique de l'ajout/suppression de machines à chaud, qui reste compliquée qu'il y ait un seul type de noeuds ou deux.
Pour le reste, on a sérieusement pensé à memcache (on l'utilise déjà pour le cache des applis web). Mais au final, c'était une fausse bonne idée : la récupération d'un fichier de moins de 200 octets n'est pas drastiquement plus rapide via memcache qu'en le lisant sur le disque. Il y a des couches logicielles en plus, des ouvertures de sockets, des copies de données... sans parler du fait de devoir gérer les éventuels problèmes de connexion sinon on risque d'avoir tout le système qui tombe (ou simplement qui ralentit) parce que memcache est en rade.
Même si ça s'éloigne des buts de FineFS, il serait intéressant (d'un point de vue théorique) de stocker les méta-données dans une base de données (je donnais l'exemple de SQLite, dont la philosophie s'accorde bien à celle de FineFS). Ainsi, il serait possible de rechercher des fichiers à partir de leurs méta-données, et non pas simplement récupérer des méta-données à partir du nom de fichier.
Cela permettrait d'avoir un système de données non relationnel (cf. Dynamo d'Amazon ou Cassandra de Facebook) qui resterait très performant même sur un très grand nombre de serveurs. Bon, je reste quand même persuadé que sur une architecture classique cela n'a pas un grand intérêt par rapport à une base de données traditionnelle (toutes les applis web utilisent un MySQL/Postgresql/Oracle quelque part)...
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
C'est assez évident pour une infrastructure dans laquelle les serveurs frontaux (qui ont besoin des fichiers) ont rarement des disques de plusieurs téra-octets, alors que l'ensemble du cluster est susceptible de stocker des téras au final. C'est plus efficace, toujours dans l'optique de lire en local les fichiers dont on va avoir besoin le plus souvent.
Maintenant, je suis d'accord que ça va complexifier le code de FineFS. Mais c'est moins complexe à gérer qu'un système où les fichiers ne sont répliqués que sur certaines machines (ta proposition précédente).
Donc, on codera sûrement un jour ce système de cache, mais en séparant intelligemment le code, pour ne pas charger la partie qui gère le cache si on n'en a pas besoin.
On ne va pas gérer un cache RAM. Pour commencer, FineFS est sans état. Même le démon n'est pas chargé en mémoire de manière continuelle (il est lancé par xinetd). Ensuite, ça complexifierait le code inutilement ; même le jour où on voudra stocker les méta-données dans une base de données, on le fera sûrement en utilisant SQLite plutôt qu'en gardant les infos en RAM.
Parce que garder un cache en RAM, c'est plus facile à dire qu'à faire de manière stable et efficace. Il faut mettre en place de la communication inter-processus, avec de la mémoire partagée ou un démon local sur lequel il faut se connecter (et hop, encore une ouverture de socket en plus !). Non, le gain est trop faible et hypothétique pour se lancer là-dedans.