背景
公司有一套基于 Windows Failover Cluster 搭建的 SQL Server DB（使用共享存储），但由于共享存储维保到期，且公司决定不继续维保，为防止共享存储异常导致 DB 不可用，故决定将 DB 迁移到新服务器（使用本地磁盘（Raid）），并升级到高版本（SQLServer2012 至 SQLServer 2019）。
1. 环境
旧
OS：Windows Server 2012 DataCenter
SQL Server：2012 SP4
新
OS：Windows Server 2019 DataCenter
SQL Server ：2019 (RTM-CU19) (KB5023049)
2. 错误日志提示 IO 问题
迁移方案中是先对旧、新服务器配置镜像同步，在配置成功后，检查错误日志时发现有报错：
There have been 5632 misaligned log IOs which required falling back to synchronous IO.
但同步状态显示正常。
一开始以为是镜像同步哪里设置的问题，由于库不大，又重新做了一遍，还是有这个错误，所以应该不是镜像同步设置的问题。
查了一些资料
大概意思就是：磁盘制造商在2011年推出了磁盘存储格式的新规范。新规范增加了磁盘扇区的大小。一些基于闪存的设备(如Fusion-io)和新的大容量磁盘(如4TB SATA磁盘)通常使用Native 4K格式。当以512或512E格式写入日志记录并以4k Native格式还原日志记录时，新的磁盘格式可能导致SQL Server错误日志中出现警告。也就是说旧服务器（很老了）和新服务器（2022）磁盘扇区不一致了才可能有这个问题。
3. 验证
在新旧服务器上分别执行如下命令：
fsutil fsinfo ntfsinfo <drive letter>
旧
如果在常规SAN磁盘上运行此命令，可以看到下面的输出。每个扇区的字节数= 512
新
512E高级格式看起来像这样，每个物理扇区的字节= 4096。这种格式的物理扇区大小为4096，但逻辑扇区大小为512。
如果是不同的格式，则有可能出现：
There have been xxxx misaligned log IOs which required falling back to synchronous IO
SQL Server存储引擎逻辑检测磁盘扇区大小，并将事务日志文件元数据和内部扇区大小匹配(512或4096字节)。当SQL Server检测到日志条目被写入时，假设扇区大小与当前SQL Server实例上的扇区大小不同，则会生成该错误信息。
如果扇区大小不通，则在以下情况都会发生这种错误：
* 日志传输
* 镜像
* AlwaysOn
出现这种报错后，为了保证一致性，SQL Server可能会从异步IO切换到同步IO。如果使用了 AlwaysOn 、镜像等同步技术，这可能会对性能产生影响。
有可能在 AlwaysOn 副本或镜像服务器上的日志写操作切换到同步IO。这可能导致主服务器和副本/辅助服务器之间同步延迟升高。
意思是，最然有报错，但不影响持续同步，如果业务量大，则同步延迟可能会较高。
4. 4096 的优势
5. 怎么修改扇区大小
这里展示查询到的方法，是否使用根据自身实际情况考虑。
原文如下：
6. 4K原生盘是否建议格式化为512 / 512e ?
每个用户的配置可能不同，并且存在非常多种的部署模式。所以很难给出建议。不过4K本机磁盘确实有优势。
一些一般性意见:
建议在相近的硬件上配置 AlwaysOn 、Mirror。
AlwaysOn、Mirror 场景可能会因副本切换到同步IO而受到一些影响。如果使用AlwaysOn 或 Mirror，建议使用相同的扇区大小。
Log Shipping 、Async AlwaysOn 、Mirror 通常不会受到此错误的影响。在事务量非常大的情况下，日志记录的恢复可能会稍微慢一些。
7. 最终方案
由于是新服务器，4k的盘也有优势，最后并没有按照上面的方法修改扇区大小。
我的库也比较小，也有足够的时间进行迁移，最后综合考虑还是使用备份恢复的方法进行迁移。
