【问题标题】:Speed and Impact of Azure SQL Geo-Replication SyncAzure SQL 异地复制同步的速度和影响
【发布时间】:2018-04-03 16:47:58
【问题描述】:

我有一个客户,其 Azure SQL 数据库是在欧洲数据中心意外创建的(该客户位于美国)。我希望使用 Geo-Replication 将其移至美国,以最大限度地减少停机时间,如下所述: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-geo-replication-portal

该数据库中等大小,大约 25GB,我似乎在以下问题上找不到任何信息:

1) 是否有办法衡量初始同步需要多长时间(即所有数据都已同步,我们可以故障转移到美国的新数据库)? 2) 是否有查看初始同步的进度? 3) 数据库的性能是否会受到初始同步(以及后续同步)的重大影响? 4) 提升服务器层级是否会改善这些结果(即同步速度和性能影响)?

【问题讨论】:

    标签: sql azure azure-sql-database geo-replication


    【解决方案1】:

    您可以使用 sys.dm_operation_status 了解故障转移的进度。下面为您提供要清算的未结交易数量

    select count(*) as OpenTX from sys.dm_operation_status where major_resource_id= 'DatabaseName' and state < 2
    

    您可以详细了解故障转移的进度here

    以下查询还为您提供复制状态和复制滞后信息。

    select 
      partner_server,
      partner_database,
      replication_state,
      replication_state_desc,
      role_desc,
      secondary_allow_connections_desc,
      last_replication,
      replication_lag_sec
    from sys.dm_geo_replication_link_status
    go 
    

    以下查询为您提供第一次同步期间的操作状态。

    select
      major_resource_id,
      operation,
      state,
      state_desc,
      percent_complete,
      start_time,
      last_modify_time
    from 
      sys.dm_operation_status;
    go
    

    保持辅助数据库与主数据库具有相同的层级和目标以避免性能损失。

    【讨论】:

    • 感谢您的回答,它最终进展得如此之快,以至于我没有真正有机会跟踪进度。对于在数据库实际上是 14 gigs 并四处走动之后查看此内容的任何人从北欧到美国东部的完全同步需要 40-45 分钟。我遇到的唯一问题是在切换期间,应用程序用户基于服务器登录,当然,它没有同步。我所要做的就是删除用户并根据登录重新创建它。
    • 尝试使用包含的数据库用户而不是服务器登录。服务器登录在故障转移期间断开连接,而包含的数据库用户则没有。
    猜你喜欢
    • 2015-01-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-08-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多