Prism Sync
I have a server A and a server B.
They have different functions but use the same database (schema)
The problem is the synchronization of migrations, so when I do it on server A, B starts to have problems.
Has anyone experienced this, or does anyone know if there is a way to maintain synchronization?
2 Replies
You've gone full bot mode! Let me fetch that AI answer for you ASAP.
This is a common challenge when working with multiple servers that share the same database schema in Prisma. Here's how you can maintain synchronization between your servers:
1. Use a single source of truth: Create a shared schema file that both servers can use. You can do this by creating a custom npm package containing the schema file, which both servers can then use to keep synchronized. This approach is recommended in the Handle multiple servers with same prisma instance discussion.
2. Synchronize migration histories: When you apply migrations on server A, make sure to apply the same migrations on server B. You can use the
prisma migrate deploy command to sync your migration history from your development environment with your database in your staging or production environment. This is explained in the Prisma Migrate in a staging and production environment documentation.
3. Use advisory locking: Prisma Migrate uses advisory locking when running production commands. This ensures that multiple migration commands cannot run simultaneously, which helps prevent conflicts when deploying to multiple servers. You can learn more about this in the Is it dangerous to start parallel migrations? discussion.
4. Check for schema drift: Before applying migrations, you can use the prisma migrate diff command to check for differences between your database and the migration history. This can help you identify and resolve any inconsistencies before they cause problems. The Check database schema compared with latest migration discussion provides an example of how to use this command.
5. Implement a deployment strategy: Consider implementing a deployment strategy wh
ere you apply migrations to one server first, wait for completion, and then deploy to the other server. This can help ensure that your database schema is always in a consistent state across both servers.
By following these practices, you can maintain synchronization between your servers and avoid issues caused by inconsistent migration states.
š¤ Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly.
In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.Hey š
If I understand correctly, you start getting issues in the second server as soon as database migrations are applied on the first server. I think this would be expected because the state of database changed.
Would creating a separate package that consists of schema file and migrations won't work for your use case as described here: https://github.com/prisma/prisma/discussions/19684?
You may also want to have a look at this section of docs:
https://www.prisma.io/docs/guides/implementing-schema-changes
GitHub
Handle multiple servers with same prisma instance Ā· prisma prisma Ā·...
Hi ! I'd like to create a second server that would handle cron jobs and long running tasks such as checking and modifying hundreds of rows. Given that he second server would introduce new model...
How to manage schema changes in a team with Prisma Migrate and Pris...
Learn how to use Prisma Migrate effectively when collaborating on a project as a team