Alcune informazioni sulla configurazione corrente:
Attualmente stiamo usando la replica del database - replica transazionale, per essere specifici - tra 2 server. Per motivi di questo post, stiamo replicando da un PRIMARY a un DR a metà strada in tutto il mondo. L'obiettivo è avere la possibilità di "passare" al DR nel caso in cui il primario si abbassi, che diventerebbe il nuovo PRIMARY. [Per il bene di questo post, continuerò a fare riferimento al server originale come PRIMARY.] Mi piace l'idea di poter "scambiare" con un server con mirroring usando la parola chiave Failover Partner nella stringa di connessione ( link ), ma sembra che sia stato creato per il mirroring del database, e al proprietario piace avere il processo "manuale", probabilmente per paura di non capire al 100% la tecnologia, e sono proprio lì con lui su quel punto. Ciò che non mi piace della nostra configurazione attuale è che, per le modifiche principali dello schema, tali modifiche sono bloccate a meno che non elimini gli abbonati e gli editori e, dopo le modifiche allo schema, ne imposti il backup. Non ho ancora uno script per automatizzarlo, quindi questo processo richiede sempre e stiamo ancora apportando modifiche significative allo schema del database.
Quindi in sostanza, non so se la replica sia la risposta. Funziona alla grande una volta impostato, ho il processo di installazione inattivo (nel senso che ho passato ore e ore a documentare i trucchi che ho incontrato configurandolo), ma ci vuole FOR-FREAKING-EVER per essere configurato, solo per farlo essere smantellato se arriva un cambio di schema più complesso di un semplice tipo di modifica "aggiungi una nuova colonna alla fine di questa tabella". Inoltre, facendo più lettura di questo in linea ha sollevato più siti affermando che il processo di commutazione del PRIMARY è il nuovo DR, quindi una volta ripristinato il vecchio PRIMARY, il vecchio DR si sincronizza con il vecchio PRIMARY e ripristina il PRIMARY e il modo in cui DR era come una seccatura, semplicemente.
Ho bisogno che le persone con esperienza di DR intervengano e mi dica quali opzioni ci sono oltre a questo. Alcuni clienti usano standard; la maggior parte usa l'impresa. Questa è una piattaforma chiavi in mano che abbiamo sviluppato e stiamo spingendo le persone a utilizzare l'impresa, ma non sarei sorpreso se ci fosse un'edizione standard in circolazione in uso nella produzione. Ognuno sta utilizzando almeno SQL 2012, e quasi tutti sono del 2016. Quali opzioni devo replicare i dati su un server diverso nel caso in cui il server / rete verso il server non funzioni? Con queste tecnologie, quanto è facile passare da server primari a server DR e quanto è facile sincronizzarli e reinserirli una volta che l'originale è online? Dovremmo codificare nella piattaforma stringhe di connessione read-write e (collezioni di) separate nell'app stessa?
Grazie in anticipo - Non ho abbastanza esperienza di DR, e l'ultima volta che ho usato qualcosa per quanto riguarda il mirroring, era con una tecnologia molto vecchia per SQL Server 7.0 che richiedeva un GUID in ogni tabella per fare riferimento - nel 2002 La mia conoscenza è superata.
EDIT: domanda riassunta: quale sarebbe la migliore strategia di mirror / replicazione che mi consenta di passare facilmente (ma manualmente) il database al secondario, e quindi di "passare" in modo semplice, quindi eseguire il backup delle sincronizzazioni primarie, cambiare primario / DR e quindi tornare indietro in modo che il primario originale sia di nuovo il primario?