Prisma migrate deploy პროდაქშენში: baseline და აღდგენა

პროდაქშენში ამუშავებ prisma migrate deploy-ს და სხვა არაფერს. ეს ბრძანება prisma/migrations-ში უკვე არსებულ მიგრაციის ფაილებს თანმიმდევრობით ასრულებს, თითოეულს ჩაწერს ცხრილში _prisma_migrations და ჩერდება. prisma migrate dev დეველოპმენტის ინსტრუმენტია: ქმნის ახალ მიგრაციებს, მეორე, ერთჯერად ბაზას (shadow database) საჭიროებს და სხვაობის პოვნისას მონაცემების განულებას შემოგთავაზებს. მისი პროდაქშენის ბაზაზე მიმართვა ბაზის დაკარგვის ყველაზე გავრცელებული გზაა.

დანარჩენი დეტალებია და დეპლოები სწორედ დეტალებში ფუჭდება: სად სრულდება ბრძანება, რა უნდა ქნა, თუ შუაში ჩავარდა, როგორ აიყვანო მართვაში ბაზა, რომელსაც უკვე აქვს ცხრილები, და რატომ არ აქვს Prisma-ს „უკან დაბრუნება“. მაგალითებში PostgreSQL-ია; MySQL და SQL Server იმავენაირად იქცევა, გარდა იმ ადგილებისა, სადაც ეს ნათქვამია.

რას აკეთებენ migrate dev და migrate deploy#

Prisma-ს მიგრაციები უბრალო SQL ფაილებია. schema.prisma-ს ცვლი, Prisma ითვლის სხვაობას ბოლო მიგრაციასთან და წერს prisma/migrations/<timestamp>_<name>/migration.sql-ს. ეს ფაილები Git-ში იდება და სიმართლის წყაროა. ორი ბრძანება სხვადასხვა სიტუაციისთვისაა:

migrate dev ერთად ხუთ საქმეს აკეთებს: ისტორიას shadow ბაზაზე ათამაშებს სხვაობის გამოსავლენად, ამუშავებს მოლოდინში მყოფ მიგრაციებს, ქმნის ახალ მიგრაციას, თუ schema.prisma შეიცვალა, ასრულებს prisma generate-ს და ასრულებს seed სკრიპტს, თუ ის მორგებულია. ის ინტერაქტიულია და სვამს კითხვებს, როგორიცაა „ბაზა უნდა განულდეს, ყველა მონაცემი დაიკარგება“, როცა dev ბაზა აღარ ემთხვევა ისტორიას.

migrate deploy ერთს აკეთებს. კითხულობს საქაღალდეს, ადარებს _prisma_migrations-ს და ასრულებს რაც აკლია. ის არ ქმნის მიგრაციებს, არაფერს განულებს, არ იყენებს shadow ბაზას, არ ამოწმებს სხვაობას და არ ასრულებს generate-ს და seed-ს. ამ სიმარტივეშია აზრი: მისი უყურადღებოდ გაშვება უსაფრთხოა და ორჯერ გაშვებაც უსაფრთხოა, რადგან მეორე გაშვება ვერაფერს პოულობს.

$ npx prisma migrate deployPrisma schema loaded from prisma/schema.prismaDatasource "db": PostgreSQL database "shop", schema "public" at "db.internal:5432"3 migrations found in prisma/migrationsApplying migration `20261012093011_add_orders`The following migration(s) have been applied:migrations/  └─ 20261012093011_add_orders/    └─ migration.sqlAll migrations have been successfully applied.

ორი რამ განსაკუთრებულ ყურადღებას იმსახურებს. პირველი, prisma db push იგივეს მსუბუქი ვერსია არ არის. ის სქემას პირდაპირ სინქრონიზებს, ისტორიის გარეშე, ამიტომ შემდგომ migrate deploy-ს დასაყრდენი არ აქვს. გამოიყენე ერთჯერადი პროტოტიპებისთვის და არასოდეს ბაზაზე, რომლის შენახვასაც აპირებ. მეორე, migrate deploy საქაღალდეს ენდობა. თუ ვინმემ უკვე გამოყენებული migration.sql შეცვალა, Prisma checksum-ის შეუსაბამობას dev-ში შეამჩნევს, deploy კი უბრალოდ ჩაწერილით აგრძელებს. არასოდეს შეცვალო მიგრაცია, რომელიც სადმე უკვე გამოყენებულია; დაამატე ახალი.

Shadow database#

Shadow database დროებითი ბაზაა, რომელსაც migrate dev ქმნის, ავსებს ყველა მიგრაციის თავიდან გათამაშებით, ადარებს შენს მიმდინარე სქემას და ისევ შლის. ასე ხვდება, რომ ვინმემ dev ბაზა ხელით შეცვალა, და ასე აგებს სწორ სხვაობას შემდეგი მიგრაციისთვის.

ჰოსტინგისთვის ეს მნიშვნელოვანია, რადგან ბაზის მომხმარებელს ბაზების შექმნის უფლება უნდა ჰქონდეს. მართულ ან გაზიარებულ ბაზაზე ის ჩვეულებრივ არ აქვს და ხედავ:

Error: P3014Prisma Migrate could not create the shadow database. Please make sure thedatabase user has permission to create databases.

გამოსავალია migrate dev-ს მეორე ბაზა მისცე, რომელიც schema.prisma-შია მითითებული:

datasource db {  provider          = "postgresql"  url               = env("DATABASE_URL")  shadowDatabaseUrl = env("SHADOW_DATABASE_URL")}

ერთხელ შექმენი მისთვის ცარიელი ბაზა, SHADOW_DATABASE_URL მიუთითე მასზე და გამოიყენე მხოლოდ დეველოპმენტისთვის. Prisma ყოველ გაშვებაზე ცარიელებს. აქედან ორი წესი გამომდინარეობს:

• პროდაქშენს shadow ბაზა არასოდეს სჭირდება. migrate deploy shadowDatabaseUrl-ს არ კითხულობს. თუ შენი პროდაქშენის დეპლოი მასზე ჩივის, იქ migrate dev-ს უშვებ.
• Shadow ბაზა არ უნდა იყოს dev ბაზა. თუ ორივე URL ერთ ბაზაზე მიუთითებს, პირველივე გაშვებაზე შენი dev მონაცემები წაიშლება.

Prisma 7-მა კავშირის URL-ები schema.prisma-დან ფაილში prisma.config.ts გადაიტანა, ამიტომ url-ისა და shadowDatabaseUrl-ის გამოცხადების ზუსტი ადგილი დაყენებულ მთავარ ვერსიაზეა დამოკიდებული. ქცევა იგივეა; თუ schema.prisma ხაზ url-ს უარყოფს, ნახე კონფიგურაციის სახელმძღვანელო შენი ვერსიისთვის.

პროდაქშენის გაშვების მორგება#

რეცეპტი მოკლეა. CI-ში ან სერვერზე, დამოკიდებულებების დაყენების შემდეგ და აპლიკაციის სტარტამდე:

1. დააყენე ზუსტად ის, რაც package-lock.json-შია: npm ci.
2. დააგენერირე კლიენტი: npx prisma generate. ის migrate deploy-ის ნაწილი არ არის და მის გარეშე გაშვებული აპლიკაცია import { PrismaClient }-ზე ვარდება.
3. გამოიყენე მიგრაციები: npx prisma migrate deploy.
4. გაუშვი აპლიკაცია.

prisma გქონდეს dependencies-ში და არა მხოლოდ devDependencies-ში, თუ მიგრაციები აპლიკაციის იმავე მანქანაზე სრულდება NODE_ENV=production-ით; წინააღმდეგ შემთხვევაში npm ci --omit=dev წაშლის CLI-ს, რომლის გამოძახებასაც აპირებ.

{  "scripts": {    "build": "prisma generate && tsc",    "migrate": "prisma migrate deploy",    "start": "node dist/server.js",    "start:prod": "npm run migrate && npm run start"  },  "dependencies": {    "@prisma/client": "^6.0.0",    "prisma": "^6.0.0"  }}

კავშირის სტრიქონი გარემოდან მოდის და არა დაკომიტებული .env-იდან. დაარქვი DATABASE_URL და მიუთითე sslmode, თუ ბაზას TLS სჭირდება - რომელი მნიშვნელობაა შენთვის საჭირო, განხილულია სტატიაში PostgreSQL-ის sslmode. საიდუმლოებებთან მუშაობის ზოგადი წესები არის სტატიაში გარემოს ცვლადები და საიდუმლოებები.

მიგრაციების გაშვება სტარტზე

"start:prod": "npm run migrate && npm run start" ვარიანტია, რომელსაც უმეტესი პატარა აპლიკაცია ირჩევს: ყოველი სტარტი მოლოდინში მყოფს იყენებს და მერე იწყებს მომსახურებას. მას რეალური უპირატესობები აქვს - დასავიწყებელი ნაბიჯი არ არსებობს და სქემა ყოველთვის ემთხვევა კოდს, რომელიც ეშვება. მინუსები იგივეა, რაც ნებისმიერ „მიგრაცია სტარტზე“ მოწყობას აქვს; EF Core-ის მიგრაციების სტატია მათ .NET-ის ტერმინებით განიხილავს:

• ჩავარდნილი მიგრაცია ჩავარდნილი სტარტია. პროცესი არანულოვანი კოდით სრულდება, პლატფორმა მას თავიდან უშვებს და ისევ ვარდება. თვალსაჩინო ნიშანი გადატვირთვების ციკლია; მიზეზი ლოგში რამდენიმე ხაზით ზემოთაა.
• რამდენიმე ინსტანცია ერთმანეთს უსწრებს. მიგრაციისას Prisma PostgreSQL-სა და MySQL-ზე advisory lock-ს იღებს, ამიტომ ერთდროულად მოსტარტე ორი ინსტანცია ერთსა და იმავე მიგრაციას ორჯერ არ გაუშვებს: მეორე ელოდება და მერე ვერაფერს პოულობს. თუ ძალიან დიდხანს ელოდება, ლოკი ვადას გადის (ნაგულისხმევად დაახლოებით ათი წამი) და ეს ინსტანცია არ ეშვება. ეს დამცავი ბადეა და არა გეგმა.
• აპლიკაციის მონაცემებს შეუძლია სქემის შეცვლა. ყველაფერს, რითაც აპლიკაცია უკავშირდება, ცხრილების წაშლაც შეუძლია.
• ნელი მიგრაციები მზადყოფნას აყოვნებს. მიგრაცია, რომელიც დიდ ცხრილზე ინდექსს თავიდან აგებს, სანამ შენი საიტი მიუწვდომელია სრულდება, რადგან აპლიკაცია ჯერ არ დაწყებულა.

&& მნიშვნელოვანია. ;-ით აპლიკაცია იმ შემთხვევაშიც ეშვება, როცა მიგრაცია ჩავარდა, და მერე სქემასთან მუშაობს, რომელსაც არ ემთხვევა. &&-ით ჩავარდნა სტარტს აჩერებს და თვალსაჩინოა.

ერთ სერვერზე ერთი ინსტანციისთვის სტარტზე გაშვება გონივრული არჩევანია. როგორც კი ორი ინსტანცია, დიდი ცხრილი ან გუნდი გაქვს, მიგრაცია ცალკე ნაბიჯად გაიტანე: CI-ის ამოცანად, release ბრძანებად ან ახალ ვერსიაზე გადართვამდე ერთჯერად გაშვებად. თანმიმდევრობა იგივეა, რაც დეპლოებში შეფერხების გარეშე პატარა სერვერზე, გადართვამდე ერთი დამატებითი ხაზით.

RE:NODE-ზე

Node.js აპლიკაციის გეგმაზე მიგრაცია გაშვების თანმიმდევრობის ნაწილია, ისევე როგორც ყველგან: შენი გაშვების ბრძანება ასრულებს npm run migrate && npm run start-ს, ხოლო DATABASE_URL სერვერის გარემოს ცვლადებშია მითითებული Startup ჩანართზე. ბაზების ჰოსტინგის PostgreSQL გეგმა გაძლევს ჰოსტს, პორტს, მომხმარებელსა და პაროლს, რომლებიც თითოეული სერვერისთვის გენერირდება; აქედან ააწყე URL და რეპოზიტორიაში ნუ შეინახავ. თუ GitHub-იდან დეპლოებ, pull ყოველ სტარტზე ახალ მიგრაციის ფაილებს მოიტანს ბრძანების შესრულებამდე - იხილე Node აპლიკაციის დეპლოი GitHub-იდან. დესტრუქციული მიგრაციის მქონე რელიზამდე დაგეგმე backup Schedules ჩანართზე ან გააკეთე ხელით Backups ჩანართზე აპლიკაციის სერვერის გეგმაში.

არსებული ბაზის baseline#

თუ ბაზას უკვე აქვს ცხრილები, მაგრამ არ აქვს ცხრილი _prisma_migrations, migrate deploy უარს ამბობს მის შეხებაზე:

Error: P3005The database schema is not empty. Read more about how to baseline an existingproduction database: https://pris.ly/d/migrate-baseline

Baseline ნიშნავს Prisma-სთვის თქმას: „ამ ბაზაში უკვე არის ყველაფერი X მიგრაციამდე, ნუ გაუშვებ ხელახლა“. ქმნი ერთ მიგრაციას, რომელიც მიმდინარე მდგომარეობას აღწერს, აღნიშნავ გამოყენებულად შესრულების გარეშე და ამის შემდეგ მხოლოდ ახალი მიგრაციები სრულდება.

1. schema.prisma შეუსაბამე ცოცხალ ბაზას. თუ Prisma არსებულ ბაზაზე მიაერთე, npx prisma db pull სქემას მისგან ჩაწერს. დააკომიტე.
2. შექმენი baseline-ის საქაღალდე. მისი სახელი ყველა შემდგომ მიგრაციაზე ადრე უნდა დალაგდეს, ამიტომ პრეფიქსი 0_ გამოდგება:

$ mkdir -p prisma/migrations/0_init$ npx prisma migrate diff \    --from-empty \    --to-schema-datamodel prisma/schema.prisma \    --script > prisma/migrations/0_init/migration.sql

1. უთხარი Prisma-ს, რომ ეს მიგრაცია სამიზნე ბაზაში უკვე გამოყენებულია:

$ npx prisma migrate resolve --applied 0_initMigration 0_init marked as applied.

1. გაუშვი npx prisma migrate deploy. ის გაცნობებს, რომ მოლოდინში არაფერია. ყოველი მიგრაცია, რომელსაც ამის შემდეგ დაამატებ, ჩვეულებრივ სრულდება.

დროშა --to-schema-datamodel ახალ გამოშვებებში გადაარქვეს (ჩამნაცვლებელია --to-schema), ამიტომ თუ შენი ვერსია მას უარყოფს, გაუშვი npx prisma migrate diff --help. ჯერ ასლზე სცადე. გუშინდელი დამპი აღადგინე საცდელ ბაზაში, ნაბიჯები მასზე გაიარე და დარწმუნდი, რომ npx prisma migrate status წერს „Database schema is up to date!“.

ახალი გარემოები - CI, ახალი staging ბაზა, ახალი დეველოპერი - baseline-ს არ აკეთებენ. მათ ცარიელი ბაზა აქვთ, ამიტომ migrate deploy 0_init-ს ნამდვილად ასრულებს და მერე დანარჩენს. ამიტომაა აუცილებელი baseline-ის SQL სქემის ზუსტი აღწერა იყოს: თუ diff-მა ინდექსი ან ნაგულისხმევი მნიშვნელობა გამოტოვა, ახალი ბაზა და პროდაქშენი ჩუმად განსხვავდება. baseline-ის შემდეგ შეადარე ისინი prisma migrate diff --from-url-ით პროდაქშენზე და --to-schema-datamodel-ით სქემაზე და ცარიელი შედეგი ელოდე.

როცა მიგრაცია ვარდება#

მიგრაცია SQL ბრძანებების სერიად სრულდება და ჩავარდნის შედეგი ბაზაზეა დამოკიდებული. PostgreSQL მიგრაციას, სადაც შეუძლია, ტრანზაქციაში აქცევს, ამიტომ ჩავარდნილი მიგრაცია ჩვეულებრივ ნახევრად გამოყენებულ ცვლილებებს არ ტოვებს. MySQL DDL ბრძანებებს მიმდინარეობისას აფიქსირებს; შუაში ჩავარდნა პირველ ნახევარს გამოყენებულად ტოვებს. ორივე შემთხვევაში Prisma ჩავარდნას _prisma_migrations-ში წერს დაწყების დროით და დასრულების დროის გარეშე და გაგრძელებაზე უარს ამბობს:

Error: P3009migrate found failed migrations in the target database, new migrations willnot be applied. Read more about how to resolve migration issues in aproduction database: https://pris.ly/d/migrate-resolveThe `20261012093011_add_orders` migration started at 2026-10-12 09:30:11 UTC failed

ყოველი შემდგომი migrate deploy ამ ბარიერს ეჯახება, სანამ საქმეს არ მოაგვარებ. ეს განზრახაა. პროცედურა:

1. წაიკითხე ნამდვილი შეცდომა. P3009 მხოლოდ იმას ამბობს, რომ ადრე რაღაც ჩავარდა. თავდაპირველი შეტყობინება არის P3018 ჩავარდნილი გაშვების ლოგში, მის ქვემოთ კი SQL შეცდომა. ტიპური მიზეზები: NOT NULL სვეტი, დამატებული ცხრილზე, რომელსაც უკვე აქვს რიგები, უნიკალური ინდექსი დუბლირებულ მონაცემებზე, გარე გასაღები არარსებულ რიგებზე, ბრძანების timeout.
2. დაათვალიერე ბაზა. სქემა შეესაბამება მიგრაციის განზრახვას სრულად, ნაწილობრივ, თუ ხელუხლებელია? PostgreSQL-ზე ჩვეულებრივ ხელუხლებელია; MySQL-ზე ხელით შეამოწმე.
3. ბაზა ცნობილ მდგომარეობაში მოიყვანე. ან ნაწილობრივი ცვლილება გააუქმე SQL-ით, ან SQL-ით დაასრულე.
4. უთხარი Prisma-ს რა გააკეთე:

# the migration did not apply (or you undid it): it will run again$ npx prisma migrate resolve --rolled-back 20261012093011_add_orders# you completed its effect by hand: never run it$ npx prisma migrate resolve --applied 20261012093011_add_orders

1. შეასწორე მიგრაციის ფაილი, თუ `--rolled-back` გამოიყენე. მიგრაციის შეცვლა, რომელიც არსად წარმატებით არ შესრულებულა, შეიძლება, რადგან ის არსად გამოყენებულა. თუ staging-ზე გაიარა და პროდაქშენზე ჩავარდა, ნუ შეცვლი: დაამატე ახალი მიგრაცია გამასწორებელი სამუშაოთი და პროდაქშენის ხელით შეკეთების შემდეგ გაუშვი --applied გატეხილზე.
2. კვლავ გაუშვი npx prisma migrate deploy.

migrate resolve მხოლოდ აღრიცხვას ცვლის _prisma_migrations-ში. ის შენს SQL-ს არასოდეს ასრულებს. ამიტომაა უსაფრთხო და ამიტომ ვერ გაგიკეთებს სქემას. მდგომარეობას npx prisma migrate status ამოწმებს: ის ჩამოთვლის გამოყენებულ, მოლოდინში მყოფ და ჩავარდნილ მიგრაციებს და არანულოვანი კოდით სრულდება, თუ ბაზა განახლებული არ არის - CI-სთვის სასარგებლო ბარიერი.

მონათესავე შეტყობინება P3008 ამბობს, რომ მიგრაცია უკვე გამოყენებულად არის ჩაწერილი; --applied ორჯერ გაუშვი, რაც უვნებელია. P3006 ნიშნავს, რომ მიგრაცია shadow ბაზაზე ჩავარდა, ანუ ისტორია ცარიელიდან ვერ ითამაშება, ყველაზე ხშირად იმიტომ, რომ ადრეული მიგრაცია იმაზეა დამოკიდებული, რაც მხოლოდ თავდაპირველ ბაზაში არსებობდა. ეს dev-ში გაასწორე და არა პროდაქშენში.

უკან დაბრუნება: down მიგრაციები არ არსებობს#

Prisma Migrate-ს down არ აქვს. მიგრაციები მხოლოდ წინ მიდის, migrate resolve --rolled-back კი აღრიცხვაა და არა გაუქმება. გაქვს სამი რეალური ვარიანტი, უპირატესობის მიხედვით:

• წინ გადაბრუნება. დაწერე ახალი მიგრაცია, რომელიც ცვლილებას აბრუნებს: სვეტი დააბრუნე, ინდექსი თავიდან შექმენი. დამატებით ცვლილებებზე ეს სწრაფია და ისტორიას გულწრფელად ინახავს.
• აპლიკაცია დააბრუნე და არა სქემა. თუ კოდის წინა ვერსია ახალ სქემასთანაც მუშაობს, ხელახლა განათავსე ის და ბაზას ნუ შეეხები. ეს შესაძლებელია მხოლოდ მაშინ, თუ მიგრაცია დამატებითი იყო, რისთვისაც ასე გეგმავენ - იხილე მიგრაციები შეფერხების გარეშე expand და contract ნიმუშის შესახებ.
• აღადგინე backup. ერთადერთი პასუხი მიგრაციაზე, რომელმაც მონაცემები გაანადგურა. ყველაფერი, რაც backup-ის შემდეგ ჩაიწერა, იკარგება, ამიტომ ეს უკანასკნელი საშუალებაა და მიზეზი, რის გამოც backup დეპლოის წინ კეთდება.

Prisma-ს შეგიძლია უკუქცევადი SQL-ის დაწერა სთხოვო:

$ npx prisma migrate diff \    --from-schema-datamodel prisma/schema.prisma \    --to-migrations prisma/migrations \    --shadow-database-url "$SHADOW_DATABASE_URL" \    --script

ბრძანება ორ მდგომარეობას ადარებს და ბეჭდავს SQL-ს, რომელიც ერთიდან მეორეში გადადის. წაიკითხე, სანამ გაუშვებ; ეს ხელით დასაწერი rollback-ის საწყისი წერტილია და არა ღილაკი. სვეტის წაშლა და მისი მონაცემების დაბრუნება ერთი და იგივე ოპერაცია არ არის.

დეპლოის ჩეკლისტი#

რელიზმა, რომელიც მიგრაციას შეიცავს, გამოშვებამდე ამ კითხვებს უნდა უპასუხოს:

ყოველ რელიზამდე, რომელიც დიდ ცხრილებს ეხება ან შეზღუდვებს ამატებს, გაუშვი მიგრაცია გუშინდელი დამპის აღდგენილ ასლზე. NOT NULL სვეტი, რომელიც ცარიელ dev ბაზაზე გადის, პროდაქშენის 200 000 რიგზე ვარდება და ამის გაგება საცდელ ბაზაზე გაცილებით იაფია, ვიდრე გადატვირთვების ციკლში.

ამჯობინე მიგრაციები, რომლებიც ორ ნაბიჯად უსაფრთხოა: დაამატე NULL-ის დამშვები სვეტი და განათავსე, შეავსე, მერე შეზღუდვა დაამატე შემდგომ მიგრაციაში. SQL, რომელსაც Prisma NOT NULL სვეტისთვის ნაგულისხმევი მნიშვნელობის გარეშე აგენერირებს, სწორედ ის ბრძანებაა, რომელიც შევსებულ ცხრილზე ვარდება.

FAQ#

შეიძლება prisma migrate dev-ის პროდაქშენში გაშვება?

არა. მას shadow ბაზა სჭირდება, ინტერაქტიულია, შეიძლება შენი მონაცემების განულება შემოგთავაზოს და ქმნის მიგრაციებს, რომლებიც Git-ში უნდა გადაგეხედა. გამოიყენე prisma migrate deploy.

ასრულებს თუ არა prisma migrate deploy prisma generate-ს?

არა. npx prisma generate თავად გაუშვი, აწყობის ნაბიჯზე. მის გარეშე კლიენტი node_modules-ში არ არის ან მოძველებულია და აპლიკაცია PrismaClient-ის იმპორტზე ვარდება.

რატომ ვიღებ P3005-ს ბაზაზე, რომელიც უკვე მუშაობს?

რადგან მას ცხრილები აქვს, მაგრამ ცხრილი _prisma_migrations არა. გააკეთე baseline: შექმენი მიგრაცია 0_init ბრძანებით prisma migrate diff და აღნიშნე გამოყენებულად ბრძანებით prisma migrate resolve --applied 0_init.

როგორ გავაუქმო Prisma-ს ბოლო მიგრაცია?

ვერ გააუქმებ. დაწერე ახალი მიგრაცია, რომელიც მას აბრუნებს, ან აღადგინე backup. migrate resolve --rolled-back მხოლოდ Prisma-ს ჩანაწერებს ცვლის ჩავარდნილი მიგრაციის შესახებ და არა შენს ცხრილებს.

უსაფრთხოა migrate deploy-ს ორი ინსტანციიდან ერთდროულად გაშვება?

უმეტესად კი. Prisma PostgreSQL-სა და MySQL-ზე advisory lock-ს იღებს, ამიტომ მეორე ინსტანცია სამუშაოს გამეორების ნაცვლად ელოდება, მაგრამ ლოდინი შეიძლება ვადას გასცდეს. მიგრაციები ერთ ნაბიჯად გაუშვი ინსტანციების სტარტამდე.

სად ინახება მიგრაციების ისტორია?

ორ ადგილას, რომლებიც უნდა ემთხვეოდეს: საქაღალდეში prisma/migrations Git-ში და ცხრილში _prisma_migrations თითოეულ ბაზაში. migrate status აჩვენებს, სად განსხვავდება.