§2024-11-28
¶ when mongoDB database has been moved or update?
- Unique ID change detected
Information that identifies this workspace has changed. This can happen when the site URL or database connection string are changed or when a new workspace is created from a copy of an existing database.
Would you like to proceed with a configuration update to the existing workspace or create a new workspace and unique ID?
- What should I choose when I update my mongoDB databse to a new version using a new URL for my RocketChat, which should I use>
When updating your MongoDB database to a new version and using a new URL for your Rocket.Chat instance, you are essentially faced with a change in the workspace's configuration due to the change in the connection string or the database itself.
Here's a breakdown of the options:
- Proceed with a configuration update to the existing workspace <-- this will keep the old structure.
What this option means: It will update the existing workspace with the new configuration (like the new MongoDB connection string or URL). When to use: Choose this option if you want to retain the same workspace and continue using the same unique ID but just update the underlying MongoDB connection details. This is generally the preferred choice when you are simply changing the MongoDB database or the URL (e.g., if the MongoDB version is being upgraded but the data needs to be retained). Pros: Your current workspace, users, and settings will remain intact, and you won’t need to create a new workspace. It’s the more seamless option.
- Create a new workspace and unique ID
What this option means: This would create an entirely new workspace with a new unique identifier, meaning you'd essentially be setting up a new instance of Rocket.Chat with a fresh MongoDB database (even though you can import data from the old one). When to use: Opt for this if you’re essentially migrating to a fresh instance and want a clean slate. For example, if you were migrating to a new database that has a different schema, or you were moving to a new environment altogether and wanted to ensure no potential conflicts with the old database. Pros: This option provides a clean setup, potentially avoiding legacy issues with the previous configuration. Which should you choose? If you're only upgrading the MongoDB version and using a new URL but still intend to keep the same Rocket.Chat instance with all the existing data (messages, settings, etc.), then you should choose to update the existing workspace. This will ensure that your Rocket.Chat instance continues to use the same unique ID and retains its configuration and data after the database change.
Make sure that the database migration or upgrade is compatible with the new MongoDB version and that Rocket.Chat is configured to handle it correctly.
If you're unsure or there are complex database migrations involved, it's always good to back up your data before proceeding.