AlwaysON Migrare dal 2014 al 2016

Ho circa 20 Listners nel 2014 con circa 500 DBS,

qual è il modo migliore per migrare questi con meno tempo morto, sforzo

La mia idea è: interrompere l'accesso Backup dbs Avvia ripristino dbs Mentre il ripristino è in esecuzione: rilasciare AOG dal 2014 Crearlo nel 2016 Fatto

Sembra semplice, ma con i dati TB questo richiederà del tempo.

Ho trovato questo -> Modi consigliati per aggiornare AlwaysOn AG dal 2014 al 2016, ma spiega in alcun modo

Spero che qualcuno possa aiutare

— Klaus Ladegaard
fonte

20 Listners on 2014 with approx 500 DBS- come sono distribuiti, ad es. quanti server (nodi)? Qual è la finestra di downtime? Qualche replica coinvolta? Una volta che ho le informazioni, fornirò una risposta che ho implementato di recente nella mia azienda con tempi di inattività minimi.

— Kin Shah,

Non dovresti aver bisogno di eliminare AOAG ... Funziona anche nella tua situazione: blogs.msdn.microsoft.com/sql_pfe_blog/2016/08/03/…

— Sean Gallardy - Utente ritirato

@SeanGallardy Dovresti aggiungere il tuo link come risposta fornendo alcuni dettagli, suppongo che questo sia ciò che OP sta cercando

— Shanky

Grazie @Grazie, aspetterò e vedrò se l'OP risponde.

— Sean Gallardy - Utente in pensione

Sei diventato famoso: dbareactions.com/post/150633969884/…

— dezso

Consiglio di configurare la spedizione dei log per migrare i database. Ore / giorni / settimane prima della migrazione pianificata, configurare la spedizione dei registri dal gruppo di disponibilità della produzione corrente (2014). È necessario eseguire i ripristini della spedizione dei log su tutti i nodi del nuovo gruppo di disponibilità (2016).

Sempre in anticipo, preconfigurare i gruppi di disponibilità sui nuovi server, ma non creare il listener.

Ciò ridurrà al minimo i tempi di inattività durante la manutenzione del ritaglio ripristinando la maggior parte dei dati prima della finestra di manutenzione.

Durante il ritaglio, i passaggi per completare la migrazione sarebbero:

Chiudi le applicazioni / annulla le sessioni esistenti.
Eseguire i backup del registro di coda per i database (2014) che si sta migrando. ( BACKUP LOG... WITH NORECOVERY)
Consentire ai processi di ripristino della distribuzione dei log di eseguire un'ultima volta oppure ripristinare manualmente i log finali su tutti i nuovi server (2016) WITH NORECOVERY.
Su uno dei nuovi server, ripristinare i database ( RESTORE DATABASE... WITH RECOVERY).
Aggiungi i database ai gruppi di disponibilità e unisciti ai server secondari.
Rilascia gli ascoltatori sulle vecchie AG (2014).
Crea gli ascoltatori sulle nuove AG (2016).
Attiva le applicazioni.

— AMtwo
fonte