合并复制的发布与订阅

合并复制必须先初始化发布服务器和订阅服务器，然后才能在它们之间传递数据。 本主题提供有关初始化期间所进行的操作的信息。 下表列出了发布的初始化操作的详细信息，在您执行列出的每个存储过程时，或在完成新建发布向导后，都会发生这些初始化操作。 在为发布首次运行快照代理后，会发生进一步的初始化。

sp_replicationdboption

将发布数据库标记为要进行复制。 除非删除复制，否则不能删除该数据库。

将系统表添加到发布数据库中（除非该数据库中已存在合并发布）。 有关系统表的完整列表，请参阅本主题中的“在发布数据库和订阅数据库中创建的系统表”部分。

sp_addmergepublication

将发布项添加到系统表中。

sp_addpublication_snapshot

将快照代理作业添加到 SQL Server 代理系统中。 作业名称的格式为 <发布服务器>-<发布数据库>-<发布>-<整数>。

sp_addmergearticle

将复制的每个对象标记为要进行复制。 除非从所有发布中删除对象的相应项目，否则不能删除对象。

将代表每个项目的条目添加到系统表中。

发布数据库的其余初始化操作在为发布首次运行快照代理时执行（以后运行快照代理时，不会重新初始化发布数据库）。 如果使用新建发布向导，默认情况下会在完成向导后创建初始快照。 如果使用存储过程，则必须运行代理作业或直接运行代理。 有关运行代理的详细信息，请参阅如何启动和停止复制代理 (SQL Server Management Studio)和复制代理可执行文件概念。

为发布首次运行快照代理：

在每个已发布的表中添加一个名为 rowguid的列，除非表中已有一个数据类型为 uniqueidentifier 并具有 ROWGUIDCOL 属性集的列（这种情况下将使用此列）。 rowguid列用于唯一标识每个已发布表中的每一行。 如果从发布中删除表，将删除 rowguid列；如果将现有列用于跟踪，则不删除该列。

在发布数据库中为每个已发布的表创建下列对象（所有对象都在 dbo架构中创建）：

将插入、更新和删除触发器添加到已发布的表中，以跟踪更改。 触发器的命名格式为 MSmerge_ins_<GUID>、MSmerge_upd_<GUID>和 MSmerge_del_<GUID>。 GUID 值从系统表 sysmergearticles中项目的项派生而来。

创建存储过程以处理已发布表的插入、更新和删除操作，并执行与复制相关的其他一些操作。

创建视图以管理插入、更新、删除和筛选操作。

创建冲突表以存储冲突信息。 冲突表与已发布表的架构相匹配： 为每个已发布的表编写脚本，然后用脚本在发布数据库中创建冲突表。 冲突表的命名格式为 dboMSmerge_conflict_<发布>_<项目>。

每次运行快照代理时，都会为发布数据库中的每个项目创建下列类型的文件（带有相应的文件扩展名）：

架构 (sch)

约束和索引 (dri)

触发器 (trg)

系统表数据 (sys)

冲突表 (cft)

数据 (bcp) -- 不会为使用参数化筛选器的发布创建。

如果发布不使用任何参数化筛选器，快照会将已发布表的数据包含在一组 bcp 文件中。 如果发布使用参数化筛选器（对于合并发布通常如此），初始快照将不包含任何数据。 将使用订阅服务器分区的快照提供数据，这将在“初始化订阅”部分进行讨论。 每个订阅都在订阅的合并代理运行并将初始快照复制到订阅数据库时进行初始化。 除了已复制对象的架构和数据之外，快照还包含发布数据库中存在的系统表、视图、触发器和存储过程（还会将一个或两个额外的系统表复制到订阅数据库中）。 有关系统表的完整列表，请参阅本主题中的“在发布数据库和订阅数据库中创建的系统表”部分。 如果重新初始化订阅，将覆盖所有已复制对象和复制系统对象。

如果发布数据库中的任何表都未使用参数化筛选器，则向每个订阅服务器上复制相同的发布快照。 如果使用了一个或多个参数化筛选器，则每个订阅的初始化方式将由下列逻辑决定：

如果在命令行中为合并代理提供了快照位置：

则从此位置应用快照。

否则，如果快照是预生成的：

则从发布数据库中的 MSmerge_dynamic_snapshots检索快照的位置，并从该位置应用快照。

否则，如果发布允许订阅服务器初始化快照：

如果已经为具有同一分区的其他订阅服务器生成了快照，则将该快照应用于订阅服务器。

否则，将生成快照并将其应用于订阅服务器。

否则，将对发布中的表使用 SELECT 语句初始化订阅服务器。 此方法要比使用订阅服务器分区的快照慢得多。

如果快照传输在任一点中断，它将自动恢复并且不再重新发送已经全部传输的任何文件。 对于每个发布项目，快照代理的传递单位是bcp 文件，因此已部分传递的文件必须全部重新传递。 不过，恢复快照可以大幅度减少传输的数据量，即便在连接不可靠的情况下也可以确保及时进行快照传递。 有关创建快照的详细信息，请参阅带有参数化筛选器的合并发布的快照。

vSphere 67 Update 2发布了许多新功能，如DRS-MM（维护模式下的DRS），针对L1TF等漏洞的CPU调度程序选项，以及新的vSphere ROBO许可，和vSphere Platinum的更新。 虽然此版本确实包含常见的错误修复，但是它的侧重点在于几个关键领域的改进。 在这篇文章中，我们将介绍这些关键改进，找出其中属于vCenter Server的重要性。 让我们来看一下vCenter Server 67 Update 2中的新功能。

vCenter Server体系结构

最近，VMware宣布将弃用外部Platform Services Controller部署模式，并在下一个主要的vSphere版本（不是更新版本）中，外部部署将不可用。 为了使此部署类型的更改顺利推进以及更好的提醒客户，vCenter Server 67 Update 2现在包含警告，通知vSphere 管理员弃用该部署模型。

警告会显示在vCenter Server Appliance安装程序UI或CLI界面。 有关详细信息，请参阅KB 60229。

Converge Tool

Converge Tool在vSphere 67 Update 1中引入，作为通过vCenter Server CLI从外部PSC部署迁移到嵌入式PSC的方法。现在，在vCenter Server 67 Update 2环境中，现在可以在vSphere Client中使用融合功能。包括所有vCenter Server和PSC的表视图或拓扑视图。轻松识别复制对象或直接登录vCenter Server Appliance Management Interface（VAMI）界面。表视图是将外部PSC融合到嵌入式的起点，简单概述了所有vCenter Server节点。

只需选择注册到外部PSC的vCenter Server，然后选择Converge To Embedded即可开始整合。在较高级别，开始融合，在vCenter Server上安装PSC服务所需的RPM，紧接着配置复制协议。然后，可以在SSO域中的所有vCenter Server完成后停用外部PSC。选择要停用的PSC，然后单击停用PSC以从其vCenter Server取消注册外部节点。停用过程也会关闭PSC应用。

注意：在退出外部PSC之前，请务必将任何其他VMware或第三方软件从外部PSC重新分配到新的嵌入式PSC节点。

基于文件的备份和还原

vCenter Server 67 Update 2包括一个新协议支持用于备份和还原vCenter Server Appliance。内置的基于文件的备份和还原现在支持一些新的协议，包括网络文件系统（NFS）和Samba（SMB）。在配置vCenter Server进行基于文件的备份或还原时，新增的NFS和SMB将协议选择提升到了7个（HTTP，HTTPS，FTP，FTPS，SCP，NFS和SMB）。目前支持的这些新协议版本是NFSv3和SMB2。

备份vCenter Server是一项重要任务，往往属于第2天的操作。 vCenter Server Appliance同时支持映像级备份和基于文件的备份。如今，许多客户利用映像级备份，就像在vSphere中的其他虚拟机（VM）一样。利用内置的基于文件的备份是备份vCenter Server的最佳方式。如果采用映像级备份与基于文件的备份相结合的备份方式，如果备份出现问题，您现在可以放心的恢复vCenter Server数据。这两种方法的结合使用可以将作为vCenter Server备份的保险政策。

注意：这些功能仅适用于vCenter Server Appliance。

基于文件的备份的另一个改进是引入了用于备份和恢复的事件通知。 vSphere 67 Update 2现在包含备份作业状态等警报以及成功和失败事件。 现在可以轻松识别vCenter Server中基于文件的备份的成功或失败。

基于文件的备份警报当然可以根据需要进行定制。 在此示例中，我们从“警报定义”窗口中看到，我们可以根据需要搜索警报，编辑和自定义。 也可以在此处配置电子邮件通知或SNMP陷阱的选项。

vSphere Health

当vSphere 67于2018年4月普遍推出时，它包含一个强大的新功能vSphere Health。 vSphere Health致力于识别和解决客户环境中的潜在问题。 从vSphere环境收集分析的遥测数据，并用于指导vSphere Administrator进行修复。

此更新版本中的vSphere Health新增功能是“类别和警报”。 在vSphere中检测到新问题时会生成警报。 与其他vCenter Server警报一样，vSphere Health警报可以设置为“确认”或“重置为绿色”。

健康 检查现在分为四个 健康 类别之一; 在线可用性，计算，网络和存储。 这种新的分组功能不仅允许对所有vSphere Health检查进行简单，有条理的视图，而且还符合改进vSphere Health整体组织的目标，因为会引入更多运行状况检查。

内容库

vSphere 67 Update 1中引入了在内容库中添加存储虚拟机模板（VMTX）文件的功能。这样就可以将本机VM模板中的虚拟机与内容库中的OVF / OVA模板一起部署。

使用内容库时，vCenter Server 67 Update 2将继续在功能上添加新功能。 当vCenter Server配置为增强链接模式时，现在可以在内容库之间同步本机VM模板。 已发布的库现在可以成为订阅者感知，允许新发布的项目复制到其他已订阅的内容库。

查看VMTX模板或从本地库的“订阅”选项卡中可以使用“发布”选项。 从本地库发布将VM模板同步到选定的订阅服务器库。

内容库的最大用例之一是能够跨vCenter Server分发VM内容，以避免从头开始重新创建VM模板配置。 内容库同步解决了此问题，允许在vCenter Server之间分发VMTX模板。

vSphere Client

我们不要忘记vSphere Client。 在最初的VMware Fling中，在使用vSphere时vSphere Client已成为我们的默认客户端。 vSphere 67 Update 2为此基于HTML5的客户端带来了一些其他增强功能。

vSphere Client的新功能是带有Code Capture和API Explorer的开发人员中心。 虽然这一流行功能始于vSphere HTML5 Web Client Fling，但它现在可在vSphere 67 Update 2中使用Code Capture允许您在vSphere Client中记录您的操作，从而提供简单，可用的代码输出。 高级技术营销架构师Kyle Ruddy在最近的一篇文章中说了这一切; “如果你曾经想要看到UI中执行的任务看起来像代码，那就是它。”

启用后，可以通过vSphere Client中的“记录”按钮轻松激活Code Capture。

接下来是API Explorer。 如果您熟悉在vSphere中使用API，您可能还记得API Explorer位于此处; 自vSphere 65发行版以来，https：// <vCenterServer-FQDN> / apiexplorer。 此更新将API Explorer引入vSphere Client，从而在与REST API交互之前删除了进行身份验证的额外步骤。 通过特定单词快速搜索vSphere REST API中可用的某些服务和方法。 例如，搜索术语“返回”会过滤API以显示相关结果。

现在，“执行”按钮显示在每个方法部分的底部，允许快速访问以通过REST API执行操作。 公平警告这是一次LIVE CHANGE，在尝试这些操作时也会显示弹出警告。

vSphere Update Manager（VUM）还为vSphere Client添加了增强功能。 现在，从一个屏幕执行所有附加，检查合规性和修复操作。 补救工作流程更新包括附加和修复多个基准，断开可移动设备，以及启用快速启动。 在vSphere Update Manager中查看ESXi映像的详细信息也在不断发展。 轻松发现所选图像中包含的所有包的名称，版本，供应商，验收等级等。

vSphere插件

vSphere 67 Update 2中的客户端插件页面也已获得更新。在以前的vSphere版本中，对客户端插件问题进行故障排除意味着筛选日志以找出问题所在。 现在可以从vSphere Client轻松查看插件的部署状态。 无法部署到vSphere Client或不兼容的vSphere插件将显示在“客户端插件”屏幕上。 从菜单中选择“管理”，然后选择“解决方案”下的“客户端插件”，访问此界面。

vSphere任务控制台现在还将显示向vCenter Server注册的每个插件的状态。 如果发生插件下载或部署故障，可以通过选择任务并查看错误堆栈来找到更多详细信息。 可以从“任务”下的“vSphere Client”菜单中找到任务控制台。

结论

最后，我们看到vSphere 67 Update 2为vCenter Server带来了大量新增强功能。 请继续关注以后的帖子，详细介绍新的vCenter Server67 Update 2功能。 如果您有任何疑问，请在下面的评论部分发布！

下面是按顺序列出配置复制的步骤:54com一、建立发布和分发服务器

[欢迎使用配置发布和分发向导]->[选择分发服务器]

->[使"@servername"成为它自己的分发服务器,SQLServer将创建分发数据库和日志]

->[制定快照文件夹]->[自定义配置]->[否,使用下列的默认配置]->[完成]

上述步骤完成后,会在当前"@servername"SQLServer数据库里建立了一个distribion库和

一个distributor_admin管理员级别的用户(我们可以任意修改密码)

服务器上新增加了四个作业:

[代理程序历史记录清除:]

[分发清除:]

[复制代理程序检查]

[重新初始化存在数据验证失败的订阅]

SQLServer企业管理器里多了一个复制监视器,当前的这台机器就可以发布、分发、订阅了。

我们再次在SQLServer企业管理器里[复制]->右键选择

->[配置发布、订阅服务器和分发],可以看到类似下图:

54ne我们可以在[发布服务器和分发服务器的属性]窗口

->[发布服务器]->[新增]->[确定]

->[发布数据库]->[事务]/[合并]->[确定]

->[订阅服务器]->[新增]->[确定]

把网络上的其它SQLServer服务器添加成为发布或者订阅服务器新增一台发布服务器的选项：

我这里新建立的JIN001发布服务器是用管理员级别的数据库用户test连接的，到发布服务器的管理链接要输入密码的可选框,默认的是选中的，在新建的JIN001发布服务器上建立和分发服务器FENGYU/FENGYU的链接的时需要输入distributor_admin用户的密码中国网管联盟www_bitscn_com到发布服务器的管理链接要输入密码的可选框，也可以不选，也就是不需要密码来建立发布到分发服务器的链接(这当然欠缺安全，在测试环境下可以使用)