Migration sur AlwaysOn

Je cherche à automatiser le rafraichissement d'une base 2014 en la passant dans une instance 2017 Always On

En théorie

1. je backupe la base source
   
   Code:

   ---

   backup database ... TO N'...'

   ---

2. je sors la base cible de son availability group
   
   Code:

   ---

   ALTER AVAILABILITY GROUP [...] REMOVE DATABASE [...]

   ---

3. je supprime la base cible des 2 noeuds du AlwaysOn
   
   Code:

   ---

   DROP DATABASE... /*Noeud 1*/

   ---

   Code:

   ---

   DROP DATABASE.../*Noeud 2*/

   ---

4. je restaure totalement la base sur le noeud 1 (recovery) : la migration est faite en phase finale de la restauration
   
   Code:

   ---

   RESTORE DATABASE [...] FROM DISK = N'\\...bak' WITH FILE = 1, MOVE N'...' TO N'E:\MSSQL\Log\..._log.ldf', RECOVERY, NOUNLOAD, STATS = 5

   ---

5. je restaure du même backup la base sur le noeud 2 (recovery or norecovery ?)
   
   Code:

   ---

   RESTORE DATABASE [...] FROM DISK = N'...' WITH FILE = 2, MOVE N'..._Log' TO N'E:\MSSQL\Log\..._log.ldf', NORECOVERY, NOUNLOAD, STATS = 5

   ---

6. je positionne la base primaire dans l'availability group
   
   Code:

   ---

   1 2	ALTER AVAILABILITY GROUP [***] MODIFY REPLICA ON N'***' WITH (SEEDING_MODE = MANUAL) ALTER AVAILABILITY GROUP [...] ADD DATABASE [...]

   ---

7. je positionne la base repliquée /secondaire) dans l'availability group
   
   Code:

   ---

   ALTER DATABASE [JCS_AGS] SET HADR AVAILABILITY GROUP = [AG-ESCADA-P04]

   ---

Là apparaît mon problème : bien que les 2 bases soient strictement identiques au temps t, impossible d'intégrer la base réplicat

1. en mode norecovery :The remote copy of database "JCS_AGS" is not recovered far enough to enable database mirroring or to join it to the availability group. You need to apply missing log records to the remote database by restoring the current log backups from the principal/primary database.
2. en mode recovery : Database "JCS_AGS" is not in a recovering state which is required for a mirror database or secondary database. The remote database must be restored using WITH NORECOVERY.

Il me demande clairement un journal de transaction inutile puisque les bases sont absolument similaires... Pourquoi devoir donc passer par un restore tran ? Comment puis-je m'en sortir ?

J'ai saisi mon erreur !

1. la restauration se faisant depuis une base d'une version antérieure, le processus de migration intervient à l'ouverture... et génère des transactions. Le même job se fait sur la secode base, mais on n'est pas garant des numéros de transactions.
2. le no de transaction servant à la synchronisation doit être postérieure à la mise dans le groupe de la base primaire... donc backup de base et de transactions doit suivre le passage de la base primaire dans le groupe... et non précéder...

... bref ! un peu con quand même de devoir passer par 2 backups...

mais si vous été aussi avec la même version vous devrez aussi passer par un backup log