Verifica della configurazione

Al termine della configurazione DR, verificare immediatamente che la configurazione sia corretta eseguendo uno switchover completo o aprendo il sito secondario per la convalida. L'apertura del sito secondario per la convalida non avrà effetto sul sistema in esecuzione nel database primario.

Apri secondario per convalida

È possibile convalidare il sito in standby senza eseguire uno switchover completo convertendo il database in standby in database in standby snapshot. Ciò consente di avviare i server WebLogic Server secondari nel sito in standby e di verificare il sistema secondario. Qualsiasi modifica eseguita nel database del sito in standby mentre è in modalità standby snapshot verrà eliminata una volta convertita di nuovo in standby fisico. I dati principali non sono interessati dalle convalide del sito secondario.

Nota:

Questa operazione deve essere eseguita con cautela: se nel database sono presenti messaggi JMS in sospeso quando viene convertito in snapshot, i server del sito in standby li elaboreranno all'avvio. Verificare che non vi siano azioni in sospeso nel database primario durante la conversione in standby snapshot.

Come utente oracle, utilizzare il broker Oracle Data Guard nell'host del database primario e convertire il database secondario in uno snapshot in standby.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
Utilizzare il comando show configuration per verificare che la conversione sia stata eseguita correttamente.
Se non sono già attivi, avviare i sistemi Oracle HTTP Server nel sito secondario.
Avviare il server di amministrazione nel sito secondario.
Avviare i server gestiti secondari nel sito secondario.
Utilizzare la console o gli script WebLogic per avviare i server gestiti secondari.
Convalidare il sito secondario.

Poiché questo non è uno switchover e il sito primario è ancora attivo, il nome frontend virtuale verrà risolto nell'indirizzo IP del load balancer del sito primario, pertanto per impostazione predefinita qualsiasi accesso al browser verrà reindirizzato al sito primario attivo.

Per accedere direttamente alle WebLogic applicazioni server del sito secondario, è necessario aggiornare il file /etc/hosts in un client controllato (ad esempio, un laptop), impostare il nome front-end virtuale da risolvere sull'indirizzo IP del load balancer front-end del sito secondario ed eseguire qualsiasi convalida da questo client.

Nota:
Verificare che il client utilizzato per le convalide non acceda al sistema tramite un proxy HTTP, poiché è possibile che il proxy HTTP continui a risolvere il nome front-end virtuale con l'indirizzo IP del load balancer del sito primario indipendentemente dal nome presente nell'/etc/hosts del client.

I client non Linux potrebbero richiedere la reimpostazione della cache DNS locale prima che un browser risolva l'indirizzo IP utilizzando la voce di file host personalizzata.

Una volta convalidato il sito secondario, andare al passo successivo per ripristinare il ruolo di standby.

Nota:
La convalida del sito secondario potrebbe richiedere del tempo.
Arrestare i server gestiti e i server di amministrazione nel sito secondario.
Utilizzare la console WebLogic secondaria per chiudere i server gestiti e il server di amministrazione nel sito secondario.
Come utente oracle, utilizzare il broker Oracle Data Guard nell'host del database primario e convertire di nuovo il database secondario in standby fisico.
Sarà necessaria la password di sistema e il nome univoco del database primario.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
Utilizzare show configuration per verificare la conversione.
Ripristinare i file /etc/hosts aggiornati.
Se sono stati aggiornati file /etc/hosts in un client in modo che punti al sito secondario per le convalide, ripristinare nuovamente il nome front-end virtuale in modo che punti di nuovo all'indirizzo IP front-end primario.

Eseguire uno switchover

Uno switchover è un'operazione pianificata in cui un amministratore ripristina i ruoli dei due siti. Dopo uno switchover, il sistema primario diventa secondario e il sistema secondario diventa primario. L'esecuzione di uno switchover comporta tempi di inattività nel sito primario.

Prima di eseguire uno switchover in una configurazione di DR ibrido di WebLogic Server, propagare le modifiche di configurazione in sospeso. Assicurarsi che non vi siano modifiche replicate nel sito secondario in sospeso.

Disabilitare qualsiasi replica pianificata durante l'esecuzione dello switchover, poiché potrebbe non riuscire e interferire con l'operazione di switchover.
Arrestare i sistemi Oracle HTTP Server nel sito principale.
Arrestare i server nel sito primario.
Utilizzare la console o gli script del server di amministrazione WebLogic per arrestare i server WebLogic nel sito primario.

Nota:
Il server di amministrazione nel sito primario può rimanere attivo durante lo switchover. Tuttavia, si consiglia di arrestarlo quando il sito è in ruolo standby perché è previsto che la configurazione del dominio nel sito in standby verrà sostituita dalla configurazione primaria durante il ciclo di vita. Se il server di amministrazione è attivo mentre ciò si verifica, verrà eseguito con una configurazione non più valida.
Eseguire lo switchover del nome DNS frontend.

Eseguire il push DNS richiesto nel server DNS che ospita i nomi utilizzati dal sistema o modificare la risoluzione dell'host del file nei client per puntare il nome virtuale front-end del sistema all'IP pubblico utilizzato dal load balancer nel sito secondario.

Per gli scenari in cui il DNS viene utilizzato per la risoluzione front-end esterna (ad esempio, il DNS OCI o il DNS commerciale), puoi utilizzare un'API per eseguire il push della modifica. Per vedere un esempio che esegue il PUSH di questa modifica in un DNS OCI, andare a GitHub, ad esempio script.

Si noti che il valore TTL della voce DNS influisce sull'RTO dello switchover: se il TTL è elevato (ad esempio, 20 min), la modifica DNS richiederà quel tempo per essere efficace nei client. L'uso di valori TTL inferiori renderà questo processo più rapido; tuttavia, ciò può causare un sovraccarico poiché i client colpiranno più frequentemente il DNS anziché utilizzare i nomi inseriti nella cache. Un buon approccio consiste nell'impostare temporaneamente il TTL su un valore basso (ad esempio, 1 minuto) prima della modifica del DNS. Eseguire quindi la modifica e, una volta completata la procedura di switchover, ripristinare di nuovo il valore originale del TTL.
Come utente oracle, utilizzare il broker Oracle Data Guard nell'host del database primario per eseguire lo switchover del database.
Sarà necessaria la password di sistema e il nome univoco del database primario.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
Se non sono già attivi, avviare i sistemi Oracle HTTP Server nel sito secondario (nuovo primario).
Avviare il server di amministrazione nel sito secondario (nuovo primario) oppure riavviare il server se è già stato avviato.
L'avvio del server di amministrazione consente di apportare modifiche alla configurazione che sono state replicate mentre questo era un database in standby.
Avviare i server gestiti secondari nel sito secondario (nuovo primario).
Utilizzare la console o gli script WebLogic per avviare i server gestiti secondari.