下载文档原格式
developerWorks 中国 > Information Management >DB2 最佳实践: 性能调优和问题诊断最佳实践，第 2 部分有条不紊地进行性能调优和故障诊断级别：初级developerWorks 中国网站编辑团队, 编辑, IBM2009 年 3 月 12 日本系列介绍了 DB2 系统性能的最优方法，分两部分。
第 1 部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。
第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。
概述就算是配置最仔细的系统也终究会发现它仍然需要一定的性能调优，并且这时我们已经搜集了的运行监控数据，将来非常便于搜集。
保持一种系统的方法来调优和进行故障诊断对我们非常重要。
当发生了一个问题，为了解决这个问题，很容易随意的进行调整。
然而，当我们这么做了，事实上定位到问题的可能性非常低，甚至让问题更糟糕。
性能调优的一些基本原则：1.有备而来，去了解系统一切正常的情况下性能怎么样。
搜集运行监视信息来跟踪一段时间内系统行为的变化。
2.了解整个场景，不要局限于你从 DB2 上看到的 – 也要搜集并分析来自于操作系统、存储、应用程序甚至来自用户的数据。
了解系统本身将有助于你解释监控数据。
3.只调整能解释你看到的症状的参数，如果连发动机都无法启动就不要更换轮胎。
不要试图通过降低 CPU 来解决磁盘的瓶颈。
4.一次只改一个参数，在更改其它参数之前先观察效果。
你可能遇到的问题类型性能问题往往分为两大类：影响了整个系统的问题和只影响了部分系统的问题。
比如某一特定应用或 SQL 语句，在研究的过程中－种类型的问题可能转化为另外一种类型的问题，或者相反。
例如造成整个系统性能降低可能是一个单独的语句，或者是整个系统的问题只是在一个特定的区域被发现。
下面我们从整个系统的问题开始。
数据库高可用是一个复杂的系统工程，本文主要介绍了几种数据库高可用的基本技术：HADR、HACMP、数据复制，存储层容灾和DPF高可用。
并结合实践实际，分别论述了它们的适用场景和技术特征。
在不同场景，不同的业务连续性级别下，我们可以组合使用这几种技术，以实现从存储，网络，系统，数据库到应用的高可用技术。
一. DB2 HADRHADR全称为High Availability Disaster Recovery ，是IBM DB2数据库上的数据库级别的高可用性数据复制机制，最初被应用于Informix数据库系统中，称为High Availability Data Replication(HDR)，IBM收购Informix之后，这项技术就应用到了新的DB2发行版中。
HADR有一主一备数据库，在9.7之前备机不可读，9.7之后备机可读可以降低主数据库的负担。
(这个Oracle的DataGuard逻辑备机可读做的就很好，但是为什么IBM会落后呢?)在数据专线带宽足且稳定的情况下，在要求主备完全数据无损的时候，推荐用同步方式传送，或者能容忍一定少量的损失，可以用准同步，但是推荐在在生产中心和同城的灾备中心之间（LAN或者MAN），如果在1000公里以上带宽和时延都没什么保障的话，比如北京和上海，最好还是用异步的方式，如果更差或者对OLTP 的实时性要求较高还可以用超级异步，当然这对流水的损失要有一定的容忍度。
HADR一个很不好的特点是不能用于DPF，只能适合单分区数据库，这就限制了数据库在高可用下的规模以及并发性。
HADR从一些实际应用来看，切换速度要比DG要快，而且切换出现故障的可能性要小些。
谈到HADR绝对不能离开DataGuard，实际上中国人民银行对两地三中心的规定就非常适合DataGuard 的两个备用数据库的方式，生产中心用主数据库，同城灾备中心用物理备用，异地灾备中心用逻辑备用。
Oracle 的DataGuard在网络故障恢复之后可以自动同步。
DB2 最佳实践: 性能调优和问题诊断最佳实践，第1 部分性能调优从配置和监控开始2009 年 3 月12 日本系列介绍了DB2 系统性能的最优方法，分两部分。
第一部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。
第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。
内容提要大多数DB2 系统都经过了性能的演变。
首先，不论出于硬件还是软件的观点，该系统首先要能被配置。
在多数情况下，这将成为系统在实施后如何运行的基础。
其次，系统一经发布，勤勉的数据库管理员（DBA）将监控系统的性能，来监测任何可能的开发问题。
如果发现任何问题，我们就进入下一个阶段- 故障诊断阶段。
每个阶段都是基于上一阶段，如果没有适当的准备，我们极有可能需要处理比较困难的问题。
本文介绍了DB2 系统性能的最优方法。
我首先涉及到一些有助于我们确保良好软硬件性能的重要原则。
然后我们讨论多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。
最后，尽管我们做了最好的准备，性能问题仍然可以降临到我们身上，我们讨论如何逐步地处理它们，并有条不紊的进行。
回页首简介任何形式的性能问题都将严重影响并降低一个系统对你组织的价值、削弱业务能力、服务中断、以及增加管理开销。
所有这些都会提升总的拥有成本。
缺乏对系统配置的基本原则，监视和性能故障诊断可能导致不同程度的性能低下，并且降低对于组织的价值。
因此，在前期花些时间去考虑基本的配置指导方针和建立健全的系统监控这样的做法，将使你对处理许多可能出现的典型性能问题，有充分的准备。
并使数据服务器得以高性能运行，以提高投资回报率。
回页首第一步：从配置上实现性能良好像InfoSphere 平衡的仓库（BW）这类的DB2 部署类型，或者那些在SAP 系统之内的系统，配置都是高度确定的。
在BW 案例中，像CPU 个数、内存对 CPU 的比率、硬盘的个数和配置这样的硬件因素，以及在预先指定版本的基础上，详尽的测试，以确定最优配置。
10.1 日常运维工具概述Runstats是run statistics的缩写，意思是收集统计信息，目的是为DB2优化器提供最佳路径选择；Reorg是重组的意思，目的是减少表和索引在物理存储上的碎片，提供性能；Reorgchk是重组前的检查Rebind是对一些包、存储过程或静态程序进行重新绑定。
几个工具的执行流程：首先通过Runstats收集表和索引的统计信息，然后执行Reorg重组，如果有必要则执行，然后再次收集统计信息。
最后，对于静态语句、存储过程等，执行Rebind绑定。
10.2 Runstats在系统运行一个查询的时候，优化器需要决定用某种方式来访问数据。
只有当DB2对表中的数据有一个大概的了解，才能知道每一步操作大约需要处理多少数据，返回多少行。
当优化器了解了这些信息后，就会根据一系列的运算，判定出各种访问途径所需要消耗的资源，然后从中选择一个消耗资源最少的方法。
最普通的Runstats就是统计表和索引中有多少行数据，有多少不同的数值。
Runstats命令使用DISTRIBUTION参数手机数据分布。
数据分布分为两种，一种叫做频率采样（Frequency）,一种叫做百分比采样（Quantile）。
当收集数据分布时，两种采样方式都会被收集。
其中频率采样是手页脚内容1机表中拥有相同数量最多的几行，比如10000行数据中9000行为10，然后500行为9，然后100行为8，剩下的部分平均分布。
如果我们制定Frequency为3的话，那么系统就会记录下来有9000行10,500行9，然后100行8，剩下的部分在估算时则假定平均分布。
而百分比采样则是将整个10000行数据分成相等大小的若干段，然后记录每一段的段首和段尾的数值，当需要查询一个数据段时（比如C1>10 AND C1<15）,就可以根据每一个数据段的启始数值加上段落的大小，估算出符合查询条件的记录数量。
理论上，数据分布收集的越细致越好。
单机环境快速实践DB2-HADR【IT168 技术文档】前言在一些实时性要求高的行业，数据库系统的高可用性和灾难恢复一直是备受关注的。
本文旨在通过介绍DB2 HADR的功能和基本的工作原理，并且通过一个实例（在单机环境中快速实践DB2-HADR），使您能更好的学习和了解DB2 HADR 的功能和基本的工作原理，你可以在这个环境中作一些简单DB2 HADR的练习和测试，并真心希望本文能够为您在学习和应用DB2 HADR在您的数据库系统的高可用性灾难恢复方面提供一些帮助。
DB2 HADR简介High Availability Disaster Recovery (HADR)是数据库级别的高可用性数据复制机制，HADR 实现是基于 HDR 的 Informix 实现的（是数据库中高可用性灾难恢复相对比较成熟的功能）。
本质上讲，HADR 是一种日志传送功能（DB2 UDB 现在支持这种功能），但它传送的不是固化的磁盘上的日志，而是日志缓冲区中的日志。
这种方法提供了充分的粒度来满足解决方案的高可用性需求。
HADR 复制发生在数据库层。
在生产环境下，HADR环境需要两台数据库服务器：主数据库服务器（primary）和备用数据库服务器（standby）。
当主数据库中发生事务操作时，会同时将日志文件通过TCP/IP协议传送到备用数据库服务器，然后备用数据库对接受到的日志文件进行重放（Replay），从而保持与主数据库的一致性。
当主数据库发生故障时，备用数据库服务器可以接管主数据库服务器的事务处理。
此时，备用数据库服务器作为新的主数据库服务器进行数据库的读写操作，而客户端应用程序的数据库连接可以通过自动客户端重新路由（Automatic Client Reroute）机制转移到新的主服务器。
当原来的主数据库服务器被修复后，又可以作为新的备用数据库服务器加入HADR。
通过这种机制，DB2 UDB实现了数据库的灾难恢复和高可用性，最大限度的避免了数据丢失。
DB2 HADR最佳实践摘要DB2 High Availability Disaster Recovery (HADR) 是一个简单易用的数据复制特性，该特性为局部和全面站点故障提供一个高可用性（HA）解决方案。
但是，由于用户的需求千差万别，因此不存在绝对理想的HADR 配置。
您的HADR 环境设置、调优和维护决策通常是权衡利弊的结果。
比如，您可能需要在数据库可用性要求和防止数据丢失之间进行权衡。
好消息是，进行权衡并不一定意味着需要以牺牲某项需求为代价。
本文就设置和维护您的HADR 环境提供了一些推荐方法，以帮助您在HADR 提供的保护与性能和成本之间找到平衡点。
本文重点关注以下领域：∙为快速故障转移设置系统∙调优参数以改进网络性能∙调优参数以最小化HADR 相关日志记录对性能的影响∙在HADR 环境中选择适当的表重组方法和负载操作HADR 简介HADR 从一个源数据库（称为主数据库）向一个目标数据库（称为备用数据库）复制数据更改。
由于这是一个无共享架构，每个数据库都使用自己的存储器。
HADR 在主数据库失败时提供快速故障转移。
您还可以在实施更新和实施维护等场景中便捷地转换主数据库和备用数据库的角色，从而将停机时间减至最小。
HADR 用途广泛，并被完全集成到DB2 数据库，不需要任何特殊硬件和软件，使用标准TCP 接口连接主数据库和备用数据库，其设置只需几个数据库配置参数。
HADR 的一个核心原则是：数据库的性能和可用性不能被某些挑战所影响，比如工作负载的突然波动（这影响备用数据库上的日志重放活动量）和服务器或网络失败（这将导致故障转移）。
为实现最优性能而调优您的HADR 解决方案应该遵循一些基本原则，以避免一段时间后出现的潜在问题。
另外，您需要了解几个涉及您的数据库维护行为的HADR 设置项目。
这个最佳实践文档将解决这些问题。
本文着眼于为您设计HADR 基础设施和配置数据库提供指南和推荐方法，从而改进HADR 相关性能，特别是日志记录和故障转移速度。
本文以 DB2 开发人员的角度介绍了在 DB2 存储过程开发中需要注意的事项和技巧。
新手如果能够按照本文介绍的最佳实践来开发存储过程，可以避免一些常见的错误，从而编写出高效的程序。
本文从初始化参数、游标、异常处理、临时表的使用以及如何寻找并 rebind 非法存储过程等常见问题进行了着重讨论,并且给出了示例代码。
DB2 提供的强大功能可以让开发人员创建出非常高效稳定的存储过程。
但对于初学者来说，开发出这样的程序并不容易。
本文主要讨论开发高效稳定的 DB2 存储过程的一些常用技巧和方法。
读者定位为具有一定开发经验的 DB2 开发经验的开发人员。
读者可以从本文学习到如何编写稳定、高效的存储过程。
并可以直接使用文章中提供的 DB2 代码，从而节省他们的开发和调试时间，提高效率。
本文以 DB2 开发人员的角度介绍了在 DB2 存储过程开发中需要注意的事项和技巧。
新手如果能够按照本文介绍的最佳实践来开发存储过程，可以避免一些常见的错误，从而编写出高效的程序。
本文从初始化参数、游标、异常处理、临时表的使用以及如何寻找并 rebind 非法存储过程等常见问题进行了着重讨论,并且给出了示例代码。
在存储过程中，开发人员能够声明和设置 SQL 变量、实现流程控制、处理异常、能够对数据进行插入、更新或者删除。
同时，客户应用（这里指调用存储过程的应用程序，它可以是 JDBC 的调用，也可以是 ODBC 和 CLI 等）和存储过程之间可以传递参数，并且从存储过程中返回结果集。
其中，使用 SQL 编写的 DB2 存储过程是在开发中常见的一种存储过程。
本文主要讨论此类存储过程。
最佳实践 1：在创建存储过程语句中提供必要的参数创建存储过程语句（CREATE PROCEDURE）可以包含很多参数，虽然从语法角度讲它们不是必须的，但是在创建存储过程时提供它们可以提高执行效率。
下面是一些常用的参数容许 SQL （allowed－SQL）容许 SQL （allowed－SQL）子句的值指定了存储过程是否会使用 SQL 语句，如果使用，其类型如何。
DB2 HADR最佳实践摘要DB2 High Availability Disaster Recovery (HADR) 是一个简单易用的数据复制特性，该特性为局部和全面站点故障提供一个高可用性（HA）解决方案。
但是，由于用户的需求千差万别，因此不存在绝对理想的HADR 配置。
您的HADR 环境设置、调优和维护决策通常是权衡利弊的结果。
比如，您可能需要在数据库可用性要求和防止数据丢失之间进行权衡。
好消息是，进行权衡并不一定意味着需要以牺牲某项需求为代价。
本文就设置和维护您的HADR 环境提供了一些推荐方法，以帮助您在HADR 提供的保护与性能和成本之间找到平衡点。
本文重点关注以下领域：∙为快速故障转移设置系统∙调优参数以改进网络性能∙调优参数以最小化HADR 相关日志记录对性能的影响∙在HADR 环境中选择适当的表重组方法和负载操作HADR 简介HADR 从一个源数据库（称为主数据库）向一个目标数据库（称为备用数据库）复制数据更改。
由于这是一个无共享架构，每个数据库都使用自己的存储器。
HADR 在主数据库失败时提供快速故障转移。
您还可以在实施更新和实施维护等场景中便捷地转换主数据库和备用数据库的角色，从而将停机时间减至最小。
HADR 用途广泛，并被完全集成到DB2 数据库，不需要任何特殊硬件和软件，使用标准TCP 接口连接主数据库和备用数据库，其设置只需几个数据库配置参数。
HADR 的一个核心原则是：数据库的性能和可用性不能被某些挑战所影响，比如工作负载的突然波动（这影响备用数据库上的日志重放活动量）和服务器或网络失败（这将导致故障转移）。
为实现最优性能而调优您的HADR 解决方案应该遵循一些基本原则，以避免一段时间后出现的潜在问题。
另外，您需要了解几个涉及您的数据库维护行为的HADR 设置项目。
这个最佳实践文档将解决这些问题。
本文着眼于为您设计HADR 基础设施和配置数据库提供指南和推荐方法，从而改进HADR 相关性能，特别是日志记录和故障转移速度。
设置您的系统执行基础设施分析在开始您的HADR 实现之前，首先需要分析将要使用的系统的状况，这个步骤很关键。
基础设施中的每个组件（比如服务器、存储器、网络和软件）都需要进行检查，以便发现潜在的故障点。
如果可能，推荐构建备用组件（例如两个网络适配器、备用服务器电源）。
分析行为的步骤之一是构建一个类似于表 1 所示的HADR 示例分析图表，描述主地址和备用地址（如果适用）上的每个组件故障和在发生故障时的预期行为的细节。
表 1. HADR 分析图表示例主地址失败地址失败描述预期结果停用影响Site A Site A 例如，AIXTivoli Systems 所有正在运行的服务器失败Automation 在 5 秒内探测到 Site A 的失败并引发 Site B 上的 HADR 强制接管事务将回滚，备用服务器接管并在 30 秒内对事务开放在完成HADR 设置的实现后，使用HADR 分析图表创建一个测试计划以验证该实现和时间预期，从而确保高可用性和数据恢复业务要求能够得到满足（或有效预期能够得以设置）。
设置HADR 的要求设置HADR 有下面几个要求：∙主数据库和备用数据库上的操作系统与DB2 版本和级别必须相同。
惟一的例外发生在执行滚动更新时。
∙用于主数据库和备用数据库的DB2 软件的位大小必须相同。
∙一个TCP/IP 接口必须在HADR 主数据库和备用数据库之间可用。
∙主数据库和备用数据库必须拥有相同的数据库名。
∙主数据库和备用数据库的表空间必须相同。
除这些要求之外，还有几个推荐方法可用于设置您的HADR 系统。
为数据库日志使用高性能专用磁盘或文件系统由于数据库更改由EE（HADR 在EEE 上不可用）中的单个日志流记录，这个流可能成为系统瓶颈。
在日志文件系统上拥有I/O 保障能力很重要。
不要在日志文件系统和表空间文件系统之间共享设备。
使主数据库和备用数据库都能访问归档日志使主数据库和备用数据库都能访问归档日志有以下几个好处：∙主数据库是归档日志的惟一数据库，但是备用数据库接管后，新的主数据库（原来的备用数据库）开始归档日志。
因此，最简单的办法是使所有日志归档到相同的位置。
如果归档设备不共享，经过几次角色替换后，有些文件将位于一个设备上，而另一些文件将位于另一个设备上。
这样，可能需要在HADR 捕获（catchup）和其他恢复操作中进行手动干预，在主数据库和备用数据库之间移动或复制日志文件。
∙共享归档允许备用数据库在本地捕获状态期间直接从归档检索日志文件，主数据库无需读取文件并通过网络将它们发送到备用数据库。
对HADR 主- 备用连接使用专用网络网络上用于HADR 的其他流量（比如客户机- 服务器通信、数据库备用和日志归档）可能会导致轻微的HADR 性能问题。
网络是HADR 场景最重要的组成部分，因为将数据库更改从主数据库复制到备用数据库需要网络连通性，以便保持两个数据库同步。
无论是专用网络还是共享网络，HADR 网络的带宽必须比数据库日志生成速度要大（可以通过在一段时间内或在其他共享网络行为中监控数据库并查看生成的日志量来计算数据库日志生成速度）。
考虑使用多个网络适配器使用多个网络适配器有助于确保一个适配器的失败不会导致失去整个网络。
考虑对数据库服务器使用一个虚拟IP 地址配置客户机以连接到使用虚拟IP 地址的数据库，在故障转移时将虚拟IP 地址从主数据库服务器重新导向备用数据库服务器。
由于该IP 地址在主数据库和备用数据库之间共享，您可以通过使应用程序只与拥有虚拟IP 地址的数据库通信来防止数据库的两个副本都作为主数据库独立运行（这种情况有时称为―分脑‖ 或―二元主数据库‖）。
考虑使用自动客户机重新路由自动客户机重新路由（automatic client reroute）在发生故障转移时将客户机从主服务器重新导向到备用服务器。
将您的系统和应用程序配置为使用一个虚拟IP 地址或客户机重新路由，但不要同时使用二者。
使用客户机重新路由而不是虚拟IP 地址的一个好处是客户机重新路由是DB2 的内置功能，不需要额外的硬件和软件。
要了解关于自动客户机重新路由的更多信息，请参见―DB2 信息中心‖自动客户机重新路由路线图。
调优参数在更改配置参数前，首先要使主系统和备用系统上的数据库管理器（DBM）和数据库（DM）的配置参数保持一致。
在主系统上进行的DBM 和DB 配置参数更改不会自动向备用系统广播，因此任何更新都需要同时在两个系统上手动完成。
对非动态数据库配置参数的更改需要对一个HADR 对进行特殊考虑。
没有一个HADR 配置参数是可动态更新的。
另外，这些参数在两个HADR 数据库上必须保持对称。
如果DB2 检测到主数据库和备用数据库上的有效HADR 配置参数（比如HADR_SYNCMODE 和HADR_TIMEOUT）不同，则HADR 连接将失败。
结果是，一旦HADR 参数已经在主数据库和备用数据库上更新，这两个数据库必须被再循环（取消激活并重新激活）以便使参数更新生效。
如果只有一个数据库被再循环，则由于HADR 配置中的不匹配，这个数据库将不能被激活。
这种类型的更新需要将一个主数据库停用。
HADR 不要求非HADR 配置参数具有对称性。
因此，不能动态更新的数据库配置参数可以通过一个滚动更新流程更新，这不需要主数据库停用。
首先，备用数据库更新，数据库被取消激活并重新激活。
然后执行HADR 接管，新的主数据库使用指定的数据库配置参数的新设置。
新的备用数据库然后可以更新，数据库将被取消激活并重新激活。
特定于HADR 的参数选择适当的 HADR 同步模式HADR 提供3 种同步模式以满足多样化的运行环境和客户需求。
同步模式是最重要的HADR 配置参数。
数据库配置参数hadr_syncmode可以设置为以下值：∙SYNC：主服务器上的事务只在相关日志写入主服务器和备用服务器上的磁盘后才提交。
∙NEARSYNC：主服务器上的事务只在相关日志写入主服务器上的磁盘且被备用服务器上的内存接收后才提交。
∙ASYNC：主服务器上的事务只在相关日志写入本地磁盘并发送到备用服务器后才提交。
一般而言，HADR 同步模式的选择取决于网络速度。
对于WAN，ASYNC 模式是推荐选项，因为传输延迟对ASYNC 模式下的HADR 性能没有影响。
对于LAN，最常用的选项是SYNC 和NEARSYNC 模式。
一种例外情况可能是：备用数据库只用于灾难恢复且业务需求能够容忍故障转移时的数据损失，或者工作负载太高，即使是LAN 也不能处理。
这时，您也许只能使用ASYNC 模式。
在SYNC 和NEARSYNC 之间进行选择时，要权衡SYNC 模式可能带来的系统性能成本（源自通信开销）和NEARSYNC 模式针对―双失败‖ 提供的安全性。
SYNC 模式SYNC 模式提供最好的数据保护。
事务提交需要两份磁盘数据副本。
这种模式的成本在于将数据写入备用数据库并将ACK 消息发回主数据库所需的额外时间。
在SYNC 模式中，日志只有在写入主磁盘后才发送到备用数据库。
日志写入和复制事件按顺序进行。
日志写入的总时间为：primary_log_write + log_send + standby_log_write + ack_message。
这种模式中的复制通信开销比其他两种模式都高很多。
NEARSYNC 模式NEARSYNC 模式几乎与SYNC 模式一样出色，且其通信开销大量降低。
在NEARSYNC 模式中，发送日志到备用数据库和将日志写入主磁盘同时进行，备用服务器的内存接收到日志后立即发送一条确认（ACK）消息。
在高速网络上，日志复制对主日志写入产生的开销很小甚至没有。
在NEARSYNC 模式中，如果主服务器失败且备用服务器在将接收到的日志写入磁盘之前也失败，则数据将丢失。
这是一种非常少见的―双失败‖场景。
因此，NEARSYNC 是很多应用程序的首选，因为它以非常低的性能损失提供近乎同步的保护。
下面展示一个逼真的NEARSYNC 性能分析示例：网络流量：100Mb/ 秒这相当于一个11.6 MB/ 秒的速度，这个速度与磁盘写入速度属于同一个级别。
由于主服务器上的磁盘写入和到备用服务器的日志复制同时进行，因此日志复制开销很小甚至没有。
鉴于如今Giga 位的网络已经很普遍，这个示例中使用的100Mb/ 秒的网络实际上是一个相对较慢的网络。
在一个Giga 位网络中，日志复制速度将为106MB/ 秒，这个速度比许多磁盘的速度还快。
ASYNC 模式在ASYNC 模式中，发送日志到备用数据库和将日志写入主磁盘同时进行，这与NEARSYNC 模式完全相同。
由于ASYNC 无需等待来自备用服务器的ACK 消息，因此主系统流量是日志写入速度和日志发送速度二者之间的最小者。
