FAQ sur l'outil Préparation à la migration
Pour préparer la migration de Server, vous pouvez effectuer les vérifications préalables à la mise à niveau et sauvegarder votre MongoDB. Pour plus d'informations, voir Préparer la migration.
- Non, l'étape de préparation à la migration n'est pas bloquante et doit pouvoir être exécutée sans perturber le fonctionnement normal de Server.
- L'outil Préparation à la migration prépare une nouvelle table de workflows qui n'est pas opérationnelle jusqu'à la fin de la mise à niveau. La nouvelle table contient les mêmes workflows et applications, mais ils seront chiffrés avec la nouvelle norme AES256 en utilisant la bibliothèque de chiffrement Alteryx, standardisée par Alteryx pour plus de sécurité.
- Le système utilise un chiffrement de niveau machine. Pour le moment, il n'existe donc aucun moyen de saisir, voir ou mettre à jour la clé AES256 utilisée pour le chiffrement.
- The time the encryption migration takes to run depends on multiple factors: the hardware performing the migration task, the location of the MongoDB, the number of workflows (including deleted workflows) in the environment, and the size of those workflows.
- When the database is hosted remotely, the migration takes significantly longer because the network link between the database and the host adds latency and additional time to transfer the data.
- The additional time required increases exponentially based on the number of workflows in the environment and how large the workflows are.
- Migration times can span minutes to a day depending on these variables. This process may take a few days to complete in extreme cases. Therefore, for environments with 1000+ workflows or environments with a remote database such as one hosted in MongoDB Atlas, we highly recommend running the Migration Prep Tool to minimize the downtime needed to perform the update. If you aren't sure this applies to your environment, there is no harm in running the Migration Prep Tool in advance of the upgrade.
Il y aura un léger impact sur les performances de l'instance Mongo. L'instance Mongo ne doit pas s'exécuter sur la même box qu'un Worker. Si le client utilise MongoDB intégré, elle se trouve dans le contrôleur, ce qui entraînera une certaine dégradation à ce niveau. Les utilisateurs ne devraient pas remarquer de baisse de performances. Les ingénieurs continuent de tester ce comportement.
Il n'y a pas de limite de temps, mais plus vous attendez pour effectuer la mise à niveau pendant que vos utilisateurs modifient les workflows, plus il y aura de workflows à convertir lors des étapes finales de la mise à niveau, c'est-à-dire pendant votre fenêtre de maintenance. Par conséquent, votre temps d'arrêt global risque d'être plus long. Dans l'idéal, exécutez la mise à niveau le jour qui suit la fin de la préparation à la migration.
Un fichier journal sera généré sous %ProgramData%\Alteryx\Service\AlteryxServiceMigration_0.log, qui expliquera s'il y a eu des échecs pendant la migration. Vous pouvez modifier cet emplacement et ce nom lorsque vous exécutez l'outil de migration avant la mise à niveau.
Il est important de vérifier que tous les workflows ont été migrés avec succès. En cas d'échec, nous vous recommandons de contacter le support pour vous aider à résoudre les problèmes.
Une dernière exécution des vérifications préalables à la mise à niveau peut également confirmer que votre base de données est à nouveau opérationnelle et que votre mise à niveau est terminée.
Oui, toutes les informations restent les mêmes.