different configured disc block size on Log shipped Secondary

• PearlJammer1

  SSCrazy Eights

  Points: 8485

  More actions

  April 3, 2018 at 8:55 am

  #410380

  I am seeing an error on our secondary server where we are sending our Log shipped database transaction logs. The error is:

  There have been 17920 misaligned log IOs which required falling back to synchronous IO. The current IO is on file E:\xxxx\dbname_log.ldf.

  I have checked that the last log backup on the Primary is also the last restored log file over on the secondary.

  Is this anything that needs to concern me in the event that I need to bring the secondary databases on line in terms of data integrity or actually being able to indeed bring them online?

  I am aware that the issue is caused by differently configured disc block sizes and I have also confirmed that this is the case. Our hosting provider has said that reformatting the discs is the only way to fix the issue - not an option!!

  Thanks

• Sue_H

  SSC Guru

  Points: 90860

  More actions

  April 3, 2018 at 1:25 pm

  #1985364

  PearlJammer1 - Tuesday, April 3, 2018 8:55 AM

  I am seeing an error on our secondary server where we are sending our Log shipped database transaction logs. The error is:

  There have been 17920 misaligned log IOs which required falling back to synchronous IO. The current IO is on file E:\xxxx\dbname_log.ldf.

  I have checked that the last log backup on the Primary is also the last restored log file over on the secondary.

  Is this anything that needs to concern me in the event that I need to bring the secondary databases on line in terms of data integrity or actually being able to indeed bring them online?

  I am aware that the issue is caused by differently configured disc block sizes and I have also confirmed that this is the case. Our hosting provider has said that reformatting the discs is the only way to fix the issue - not an option!!

  Thanks

  It affects performance more than anything as SQL Server will fall back to synchronous IO from asynchronous, just as the message indicates. 
  You may want to look into using trace flag 1800. There is some information about this in the following: 
  FIX: Slow synchronization when disks have different sector sizes for primary and secondary replica log files in SQL Server AG and Logshipping environments

  This blog post is a pretty good explanation of things - a lot which you already know. Just has more details on all of it:
  Message misaligned log IOs which required falling back to synchronous IO in SQL Server Error Log
  
  Sue

• PearlJammer1

  SSCrazy Eights

  Points: 8485

  More actions

  April 4, 2018 at 2:40 am

  #1985415

  Ok thanks Sue.
  So from reading those articles, it seems that things would be worse if using mirroring or always On AG groups.
  It mentions for Log shipping that the restore of the log may just take a little longer - I can live with that as our databases are not highly transactional.

  It something I am going to raise with out hosting provider.
  Just for info, incase anybody else has, or is thinking of a similar setup:
  Our primary is an Ec2 instance in AWS and we asked our hosting provider to set up our DR server in AZURE. It looks like the default configuration for these 2 technologies is different - unless our hosting provider has missed something in the initial configuration.