Ciò significa che per esempio possiamo fare in modo che che i client effettuino attività di reportistica su un determinato DB di replica senza
impattare sulle performance del Principal che in questo modo può far fronte a tutte le richieste degli utenti e portar avanti il lavoro sui DB Core business aziendali. Ma anche il backup può beneficiare di questa possibilità.
Abbiamo alcune restrizioni sui tipi di backup che possiamo implementare sulle repliche ma nonostante tutto il giochino ci torna molto utile.
Sui server di replica possiamo effettuare Backup Full, di file e filegroup a patto che si specifichi l'opzione COPY_ONLY.
Il Backup differenziale non è supportato sulle repliche, mentre il backup del transaction log è pienamente supportato.
Effettuare il backup del transaction è indispensabile per mantenere contenuta la dimensione del file *.ldf e per mantenere basso il numero dei virtual log.
Nel mio post precedente spiego perchè un numero elevato di Virtual log potrebbe degradare le performance.
La possibilità di effettuare il backup del T-Log sui server di replica concorre a mantenere le performance del server Principal ai livelli ottimali dato che solleva quest'ultimo dalla necessità di implementare anche questa attività che potrebbe essere anche molto onerosa in termini di I/O.(Meno I/O faccio più veloce vado !!)
Il backup del T-Log dovrebbe essere automatizzato ed implementato a intervalli regolari ma per poterlo fare sulle repliche dobbiamo configurare l'Availability Group in modo corretto.
Vediamo come fare.
Espandiamo il nodo Always On dal SQL Server Management Studio connesso al server primary e click destro sull'availability Group che vogliamo configurare
Entriamo nella page Backup Preference e selezioniamo il'impostazione adeguata alle nostre esigenze. Qui trovate la descrizione completa dei valori.
Una volta selezionata la locazione d'esecuzione del backup e la Backup Priority la fase di configurazione dell'Availability Group è conclusa.
Dobbiamo ora creare i Job per effettuare il backup del T-Log.
Per evitare di dover creare un Job su ciascun nodo di replica possiamo appoggiarci alla funzionalità Multiserver Administration
Anzitutto scegliamo il server che sarà il Master della Multiserver Administration.
A questo punto scegliamo i server Target su cui eseguiremo i job
Ed ecco il risultato
Ora si deve creare sul server Master il job d'esecuzione T-Log Backup.
A questo punto ci viene in aiuto la funzione sys.fn_hadr_backup_is_preferred_replica.
La funzione restituisce 1 se il database è la replica preferita su cui eseguire il backup, 0 in tutti gli altri casi.
Provate ad eseguire la seguente query su un ambiente Always On e scoprirete quale replica effettua il backup
Declare @ExecBackup bit
Set @ExecBackup = sys.fn_hadr_backup_is_preferred_replica('MyTestDatabase')
If (@ExecBackup = 1)
Select 'Effettuo il backup su questo server'
else
Select 'Il server non è la replica adeguata al backup'
Eseguendola su entrambi i miei nodi di replica ottengo il seguente risultato
Dal SQL Agent dell'istanza Master selezioniamo Multi-server Job e creiamo il nostro processo.
Questo è il T-SQL per la creazione del nostro job :
Declare @ExecBackup bit
Set @ExecBackup = sys.fn_hadr_backup_is_preferred_replica('MyTestDatabase')
If (@ExecBackup = 1)
begin
Backup Log MyTestDatabase to disk = '\\win8dc\MySharedFolderForAvailabiltyGroup\T_Log_Backup.trn' with compression
Restore verifyonly from disk = '\\win8dc\MySharedFolderForAvailabiltyGroup\T_Log_Backup.trn'
end
L'istruzione Restore verifyonly esegue una verifica del file di backup, non si sa mai.... ;-)
Scheduliamo quindi il job secondo le nostre policy
e selezioniamo i Server Target
Click su Ok ed il job è creato.
Sui server target ci troveremo il job e sarà su questi che il backup verrà eseguito, sollevando il principal da questa incombenza...
Ciao
Luca
Nessun commento:
Posta un commento