Si je comprends bien, vous n’avez eu aucun problème à suivre les étapes précédentes, à créer/modifier import.yml à côté de app.yml, à reconstruire le conteneur import, et maintenant vous ne pouvez même plus y accéder. Est-ce exact ? C’est étrange, en effet !
Que retourne cette commande ? ls -l /var/discourse/containers
C’est toujours pareil : app.yml et import.yml (plus un fichier “bak” de app.yml).
Il pourrait y avoir des “problèmes” car j’ai essayé d’installer ceci sur Lightsail 1 Go (qui est initialement de 940 Mo et après la mise à jour d’Ubuntu devient “921 Mo”). J’ai utilisé l’installation officielle et ce qui a été installé était quelque chose comme 3.3.* beta-quelque chose (tandis que Wiki montre 3.2 comme la version stable la plus récente). L’installation prend 1h15-1h20 avec 4 Go de swap. le “launcher rebuild import” environ 2h.
Quelque chose pourrait-il être mal terminé en raison du manque de mémoire ?
Au fait, les fichiers de sauvegarde de la configuration 2 Go seront-ils lisibles dans la configuration 1 Go ?
A-t-elle réussi ? Après une reconstruction, le conteneur doit être démarré.
Vous ne pouvez pas entrer dans le conteneur s’il n’est pas démarré (./launcher start import)
Ce serait probablement le cas. Il existe plusieurs sujets liés au manque de mémoire/swap et à l’échec de reconstruction ici — il n’y a généralement pas d’autre choix que d’augmenter la RAM/swap.
Je ne suis pas un expert ici, mais j’espère que quelqu’un pourra vous donner un meilleur aperçu.
Apparemment, la RAM est un problème. Pour le Lightsail 2 Go/2 Go, l’installation propre est environ 3,5 à 4 fois plus rapide et la reconstruction du conteneur d’importation était environ 10 fois plus rapide (voire plus).
Cependant, je crains que le script d’importation ne fonctionne pas pour phpBB 3.3.3. Quoi qu’il en soit, j’ai essayé deux fois avec le même résultat : un seul mot d’un nom de catégorie (sur environ 10 catégories) a été importé comme une « catégorie » vide. La sauvegarde textuelle MySQL est assez petite, 2,66 Mo. Tous les préfixes de table sont conformes aux exigences. Pas d’images, pas de smileys, etc.
Au final, pas de forums, pas de catégories de forums ni de messages, mais tous les utilisateurs (quelques centaines) ont été importés correctement avec leurs statistiques.
Il semble que phpBB 3.3.3 soit la mise à jour qui a modifié quelque chose concernant la version MySQL utilisée, mais il s’agit ici d’un fichier de sauvegarde, donc cela ne devrait pas avoir d’importance après tout.
Des idées sur ce qui pourrait être vérifié d’autre ?
Vous voulez dire 4 Go pour ouvrir/lire/analyser ce fichier texte de 2,6 Mo ? Êtes-vous le développeur de Discourse ? Un exécutable binaire pour lire ce dump (en extrayant toutes les données utilisées par Discourse) et l’enregistrer dans autre chose devrait, à mon avis, peser environ 200 Ko avec, disons, un tampon de 100 Ko (sans se soucier de l’inclusion de toute la base MariaDB pour cette action simple).
Je pense que ce n’est pas une question de RAM. La procédure a été rapide et a affiché la progression de l’importation pour les tables importées. Elle ne s’est pas “arrêtée”. La table des utilisateurs se trouve à la fin du dump, après les sujets, etc.
Je voulais refaire cela, en expérimentant la copie/coller de cette table des utilisateurs en haut et en effectuant les mêmes étapes que celles décrites dans le manuel/la page ci-dessus (également avec un dump créé par phpMyAdmin au lieu de phpBB), mais maintenant Discourse refuse de démarrer la procédure en essayant de se connecter à distance bien qu’aucune donnée de connexion n’ait été ajoutée.
J’ai reconstruit le conteneur d’importation, mais peut-être faut-il supprimer quelque chose d’abord ?
Je gagne ma vie en soutenant Discourse et j’ai effectué plus de migrations que je ne peux en compter, mais je pense que cent ou plus. 2 Go fonctionneront probablement, surtout si vous n’avez que quelques milliers de sujets et d’utilisateurs, mais comme vous en avez besoin pour une courte période, plus de RAM n’est pas cher et ne peut pas nuire. Je suis d’accord que ce n’est probablement pas le problème.
Lorsque le script s’est exécuté, a-t-il compté les catégories, les utilisateurs, les sujets et les messages ?
Le script ignorera les données importées et créera des données de champs personnalisés pour les ignorer à l’avenir, donc pour le réexécuter, vous devez effacer la base de données Discourse. Puisque vous dites qu’il n’a rien importé, on ne sait pas si c’est nécessaire. Il semblerait que soit il l’a importé et vous ne le trouvez pas pour une raison quelconque, soit il a échoué parce qu’il n’a pas trouvé les données, et vous devez modifier le script d’une manière ou d’une autre ; dans aucun de ces cas vous ne devriez avoir besoin d’effacer la base de données.
Pas exactement :
« tous (quelques centaines) d’utilisateurs ont été importés correctement avec leurs statistiques »
J’ai essayé de reconstruire le conteneur à nouveau. Les mêmes paramètres. Je n’ai rien changé et après l’étape :
import_phpbb3.sh # à l’intérieur du conteneur Docker
le script affiche maintenant :
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/mysql2-0.5.6/lib/mysql2/client.rb:97:in `connect’: Unknown database ‘phpbb’ (Mysql2::Error)
Peut-être y a-t-il encore des fichiers temporaires précédemment utilisés à supprimer ?
J’ai finalement utilisé le dump de phpMyAdmin. Existe-t-il un exemple (ou des spécifications plus détaillées) sur la façon de créer les sections de mappage dans le fichier settings.yml (d’importation) ?
Ma table php_forums ressemble à ceci :
Il semble que quels que soient les identifiants que j’utilise et peu importe si je spécifie également la section « new_categories: », le message généré par le conteneur d’importation est correct :
création de nouvelles catégories
11 / 11 (100.0%) [2803 éléments/min] n]
création de catégories
11 / 11 (100.0%) [2704 éléments/min]
mais ce qui est créé, ce sont deux catégories principales (qui étaient des « forums » dans phpBB avec l’ID parent 0) et une sous-catégorie vide dans chacune d’elles. La procédure importe tous les messages, mais ils sont tous « orphelins ».
Eh bien, en fait, j’ai fait un pas en avant pour corriger ma propre erreur : j’ai simplement placé des commentaires dans le fichier settings.yml en utilisant le style C/C++, à la fin des lignes. Cela a apparemment empêché les sous-forums d’être « traités » (bien qu’aucune erreur n’ait été affichée).
J’ai ajouté les catégories et sous-catégories comme « nouvelles » et j’ai mappé les anciens identifiants.
Il reste tous les messages non attachés à une catégorie. Ces sujets sont-ils stockés dans une table Postgres ? Comment peuvent-ils être supprimés ?
J’ai ajouté quelques corrections à phpbb_mysql.sql au moins pour permettre au script de créer toutes les catégories d’origine, mais ce n’est pas suffisant.
Lors du traitement des sujets/messages, il y a juste une longue liste du type :
Le message parent [un certain id] n'existe pas. Ignoré [un certain id]
et, bien sûr, aucun message n’est importé.
Je me demande si quelqu’un pourrait confirmer que les scripts par défaut ne fonctionnent pas avec les tables phpBB 3.3.3 ?
Finalement, j’ai pu utiliser le fichier dump phpBB3.3.3 sans définir les catégories comme nouvelles et sans tout le mappage dans le fichier settings.yml.
Avec le fichier dump original phpBB_mysql.sql, le script de migration s’arrête à l’étape où les catégories sont chargées et affiche une erreur concernant un « corps de catégorie vide ».
Cela se produit si le champ « forum_desc » dans la table « phpbb_forums » pour les catégories de forums principales (qui n’ont pas de catégories parentes).
Après avoir importé seulement cette première catégorie partiellement, le reste semble être corrompu.
L’utilisation d’une installation fraîche et la saisie de texte dans les champs de table ci-dessus semblent résoudre ce problème.
