June 4, 2018 at 2:30 pm
I am trying to better understand this
It talks about log redo, but what IS that exactly?
I always though log redo was like rolling forwards so if your server crashes and you start it back up, SQL scans the logs to see if anything that was in the t-log never made it to the database, then it rolls all those transactions forwards (hopefully) and all is well.
Is this the same thing here? I don't follow that?
I know that in the availability group (sync commit not async) it sends log data over to the secondary and the secondary reads that, writes it to the secondary DB, hardens it, and then sends back an ALL OK signal to the primary which marks it down as good and moves on. (https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-2017#HowSyncWorks)
Where does the log redo come into play?
Is the writing of the log data the secondary receives from the primary considered log redo or roll forwards? Does that mean the secondary is perpetually "rolling forward" the log as it keeps in sync with the primary?
Thanks!
June 4, 2018 at 5:58 pm
Maxer - Monday, June 4, 2018 2:30 PMI know that in the availability group (sync commit not async) it sends log data over to the secondary and the secondary reads that, writes it to the secondary DB, hardens it, and then sends back an ALL OK signal to the primary which marks it down as good and moves on. (https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-2017#HowSyncWorks)Where does the log redo come into play?
Is the writing of the log data the secondary receives from the primary considered log redo or roll forwards? Does that mean the secondary is perpetually "rolling forward" the log as it keeps in sync with the primary?
Thanks!
You've basically got it. Redo is "Re-perform this action". From your post:
"I know that in the availability group (sync commit not async) it sends log data over to the secondary and the secondary reads that, writes it to the secondary DB, hardens it, and then sends back an ALL OK signal to the primary which marks it down as good and moves on.
...redo is the part I underlined.
For your last question: Yes, Availability Group replication is basically "in-line log-shipping" or "perpetual crash recovery".
Eddie Wuerch
MCM: SQL
June 4, 2018 at 6:18 pm
Eddie Wuerch - Monday, June 4, 2018 5:58 PMMaxer - Monday, June 4, 2018 2:30 PMI know that in the availability group (sync commit not async) it sends log data over to the secondary and the secondary reads that, writes it to the secondary DB, hardens it, and then sends back an ALL OK signal to the primary which marks it down as good and moves on. (https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-2017#HowSyncWorks)Where does the log redo come into play?
Is the writing of the log data the secondary receives from the primary considered log redo or roll forwards? Does that mean the secondary is perpetually "rolling forward" the log as it keeps in sync with the primary?
Thanks!
You've basically got it. Redo is "Re-perform this action". From your post:
"I know that in the availability group (sync commit not async) it sends log data over to the secondary and the secondary reads that, writes it to the secondary DB, hardens it, and then sends back an ALL OK signal to the primary which marks it down as good and moves on.
...redo is the part I underlined.
For your last question: Yes, Availability Group replication is basically "in-line log-shipping" or "perpetual crash recovery".
Thanks!
Also...well crap so then the issue with multiple redo threads is really a big deal (potentially) for performance. Okay, I will be sure to look into that further.
It is NOT an issue only with database recovery after startup, but an ongoing operation integrel to how HA AG works.
Thanks!
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply