Это видео недоступно.
Сожалеем об этом.
Senior DBA Class - Transaction Log Shipping Tips and Tricks
HTML-код
- Опубликовано: 15 мар 2021
- In theory, log shipping is easy: just restore your transaction log backups. In reality, you need to understand how to deal with unplanned failovers, reversing log shipping the other direction, and fixing a lagging secondary.
Thanks, buddy. This was very helpful!
Glad to hear it!
Microsoft gave us some more entitlement in the SQL Server 2019 Licensing guide.
(Up to three secondary replicas)
Failover Basics
For each on-prem server OSE licensed with SQL Server 2019 and covered by active SA, customers can use the
following passive replicas in anticipation of a failover event:
• One passive fail-over replica for High Availability in a separate OSE
• One passive fail-over replica for Disaster Recovery in a separate OSE
• One passive fail-over replica for Disaster Recovery in a single VM on Azure
And they allow for using the secondaries for maintenance like
• Database consistency checks
• Log Back-ups
• Full Back-ups
So now we can cover Availability with Always-On while also covering disaster with Log Shipping and toss a copy to Azure if we really want for kicks.
no Extra SQL licensing ;)
Standby mode does not support log shipping with different SQL versions, only NORECOVERY mode does.
Thank you for upload
@brent can you share the link to the white paper that demonstrates the google cloud process that you referenced?
Why is log shipping recommended then over Full back up and restore approach?
Because full backups & restores take a long time.
If you use log shipping you're constantly restoring to the secondary. So your only ever a few minutes behind. all you have to do is wait for the last transaction log back up to apply and your done.
if you do full backs/restore you have to wait for the entire back up to transfer and be pulled into SQL Server
thanks you