Questions tagged «mirroring»

有关数据库镜像的问题-一种用于同步或异步创建和维护数据库的精确副本的技术。

2
通过网络以较低的停机时间迁移大型SQL Server数据库的最佳方法
问题定义 我们的数据库服务器需要转移到另一个数据中心。它在Microsoft SQL Server 2012 Enterprise(64位)上运行,并包含两个大约2TB和1TB的数据库。 为此,几乎没有停机时间甚至没有停机时间将是理想的。 工作量 这些数据库用于.NET网站,并且会不断更新。 周末不可用它是可以接受的。在切换到新数据库之前,当前正在使用的数据库将保持唯一。 理想情况下,只需更改DNS条目以指向新的数据库服务器,同时确保不更新数据库,即可进行该切换。 此外,只要将从一台服务器切换到另一台服务器的停机时间(停机时间)保持在较低水平,此操作所花费的时间并不重要。 考虑的方法 备份还原 过去已经做到了这一点,但是即使通过内部网络完成,也要花费大量的停机时间,因此比通过Internet 更有效 日志传送 据我了解,该方法将通过配置主/从服务器并将主数据库的精确副本传输到只读的从服务器,从而最大程度地减少停机时间。如上所述,不需要访问从属服务器,我们只需要一种在不破坏数据的情况下拥有主数据库副本的方法。 就资源利用率而言,它似乎也相当有效,并且不会对主服务器性能产生太大影响。 我对这种方法可能不对,请随时纠正我。 数据库镜像 我不太了解这种方法,但似乎是一个有效的选择。不需要实时同步,并且主机的性能非常重要,因此,如果选择这种方法,异步将是必经之路。 还有其他选择吗? 该服务器直接在裸机硬件上运行,因此不幸的是不能选择较低级别的解决方案。也许有更好的方法可以做到这一点? 约束条件 如上所述,这些数据库很大,难以维护,但这是另一个问题。 SQL Server的版本将相同(Microsoft SQL Server 2012 Enterprise 64位)。 它必须在两个数据中心之间通过网络传输,因此很有可能在Internet上传输。不幸的是,无法将磁盘从一个站点发送到另一个站点进行初始同步。为传输提供某种安全性将是理想的,但是我们会尽力解决这种情况。 这应该可以很好地概述我们对这项任务的需求,希望你们中的某些人不得不面对这种情况。

2
什么会导致镜像会话超时然后故障转移?
我们有两个运行SQL Server 2005 SP4且具有累积更新3的生产SQL Server。这两个服务器都在相同的物理计算机上运行。DELL PowerEdge R815具有4个12核心CPU和512GB(yes GB)的ram,以及用于所有SQL数据库和日志的10GB iSCSI SAN连接的驱动器。操作系统是带有所有SP和Windows更新的Microsoft Windows Server 2008 R2企业版。操作系统驱动器是3个72GB 2.5英寸15k SAS驱动器的RAID 5阵列。SAN是具有48个10k SAS 3.5英寸驱动器的Dell EqualLogic 6510,在RAID 50中进行配置,分割为两个SQL Server的多个LUN,并且也共享一台Exchange机器和几台VMWare服务器。 我们有20多个数据库,其中有11个使用见证服务器以高可用性进行了镜像。见证服务器是运行SQL Server实例的低功耗计算机,该实例仅用于提供见证服务。最大的镜像数据库为450GB,可生成约100-300 iops。数据库镜像监视器报告当前的发送速率约为100kb至10mb /秒,并且镜像提交开销(通常为0毫秒)。镜像服务器与主体保持一致没有问题。 我们一直在经历镜像故障转移。有时,单个数据库将进行故障转移,而有时几乎所有数据库将同时进行故障转移。例如,昨晚,我们进行了11个数据库故障转移中的10个,其​​余的数据库保持可访问性,直到我手动对其进行故障转移。 我已经经历了一些故障排除步骤来尝试确定问题,但是到目前为止,仍无法解决问题: 1)该机器随附Broadcom BCM5709C NetXtreme II 4端口千兆网络适配器,我们最初将其用作主要网络连接。此后,我们在两台计算机上都安装了Intel PRO / 1000 PT双端口服务器适配器,以消除NIC的问题。 2)所有数据库每晚都有一个自动完整备份,以及有关镜像数据库的日志备份。日志文件的使用情况受到监控,很少使用超过15%。主数据库的日志文件为125GB,由159个虚拟日志文件组成,大小从511MB到1GB不等。TempDB位于其自己的LUN上,由24 x 2GB文件组成。 3)在见证服务器上的SQL Server登录没有显示以下任何错误:与数据库“ Data”的镜像连接“ TCP://SQL02.DOMAIN.INET:5022”的超时在30秒后没有响应。检查服务和网络连接。 主服务器和辅助服务器上的SQL Server登录显示与镜像有关的消息: 30秒钟后,到“ TCP://SQL01.DOMAIN.INET:5022”的镜像连接超时,数据库“ Data”无响应。检查服务和网络连接。 …

1
镜像-无法访问服务器网络地址
我已经安装了SQL Server 2008 R2。它包含三个实例。 默认(MSSQLServer) 第一个例子 第二审 所有这些都是作为网络服务登录。 默认实例是主体服务器,第一个实例是镜像,第二个实例是见证服务器 最初,我对主体数据库进行了完整备份和事务日志备份。通过保持相同的数据库名称将其还原到第一个实例,并且恢复状态为“不可恢复” 最后,我启动了镜像,并收到以下两条错误消息。

2
如果我对一个数据库进行故障转移,那么共享相同镜像端点的其他数据库是否也会进行故障转移?
我们有两个用于在单个SQL Server实例上进行镜像的数据库设置:测试数据库和生产数据库。两者都使用完全相同的端点镜像到另一台服务器。 如果我进入测试数据库的“数据库属性”并单击“故障转移”按钮,由于两个数据库共享一个镜像端点,并且它们的“服务器网络地址”属性相同,它也会对生产数据库进行故障转移吗? 我很担心,因为当我为第二个数据库设置镜像时,我不必配置任何新内容。它只是使用了所有现有信息。 如果我使用“数据库属性”中的“故障转移”按钮,会导致对使用该端点的所有数据库进行故障转移,还是仅对我正在查看其属性的特定数据库进行故障转移?

2
如何创建在镜像状态更改时运行作业/过程的事件通知
我按此顺序问这个问题。是否可以使用T-SQL通过TCP发送字符串? 雷木斯·鲁萨努(Remus Rusanu)暴露了似乎是解决我问题的最佳解决方案,但是...我还不成熟,无法理解和理解他所说的一切。 到目前为止,我认为我需要为DATABASE_MIRRORING_STATE_CHANGE创建通知事件,对吗? 我如何创建此事件通知,使其触发时在表中插入一行,该行存储时间戳和来自通知的ID。 到目前为止,我为每个ID设置了一个警报,每个警报都运行这样的工作(此示例的ID为1): DECLARE @state AS varchar(50); SELECT @state = mirroring_state_desc FROM SYS.database_mirroring WHERE mirroring_guid IS NOT NULL; IF (@state IS null) SET @state = ' '; INSERT INTO MirroringAlerts (DateTime, alertID, alertDesc, Sync, alertCreator) values (SYSDATETIME(), 1, 'Principal synchronized with W ', @state, @@SERVERNAME) 基本上,我在此数据库中创建一个内部日志: CREATE …


2
镜像数据库上的事务日志维护
SQL Server版本:2008 R2 Enterprise SP2 我试图解决我们的SQL Server维护问题,遇到了一些我认为不正确的问题。我们有一个生产实例,其中有3个数据库都异地镜像到DR实例。 在查看DR实例时,我注意到LDF文件非常庞大,对于频繁使用的数据库,该文件超过35GB。 我知道这可能是由于镜像数据库处于完全恢复模式,并且从未备份过日志,它们只会继续增长直到驱动器空间用尽。 我们正在主体数据库上进行日志备份,而我的问题是在镜像上进行日志备份的陷阱是什么? 在进行日志备份之前,至少必须完成一次从镜像的完整数据库备份,在这种情况下,由于镜像是镜像,是否需要使用特殊选项? 同样,这是MIRROR数据库上的事务日志维护建议。 感谢您的输入

3
如何检查SQL Server端点的安全设置?
我正在为我们的SQL Server开发人员创建一个TEST环境。 在生产中,我们有3个SQL Server,SQL01其中包含多个镜像到的数据库SQL02。 SQL03在“具有自动故障转移功能的高安全性”或同步配置中充当见证人。 我已经使用VMWare P2V将所有三台计算机虚拟化到单独的硬件上,重新配置了计算机的SID,并从这些新计算机中清除了生产服务器的IP地址。 我起初忘记给生产见证机器加黑洞,因此​​TEST机器上的数据库仍将SQL03机器用作见证。注意到这个问题,我决定在TEST上重新配置数据库,以指向新虚拟化的TEST见证者,称之为TEST03。 要重新配置数据库以使用新的见证服务器,我在主服务器上输入了以下命令TEST01: ALTER DATABASE [TestDB] SET WITNESS = 'TCP://TEST03.domain.inet:5022'; 响应是意外的: The ALTER DATABASE command could not be sent to the remote server instance 'TCP://TEST03.domain.inet:5022'. The database mirroring configuration was not changed. Verify that the server is connected, and try again. 我对这个错误消息非常困惑,因为该配置在生产机器上确实有效,并且在测试机器上没有进行任何修改。 为了使它起作用,我需要LOGIN在测试见证人上创建一个: CREATE …



2
镜像分发服务器
有人成功镜像了分发数据库吗?我们有专用的服务器作为分发服务器。它处理我们从产品到报告的所有推式复制。我们希望在附近构建一个相同的服务器,以防分发服务器崩溃。有没有人成功建立这样的东西?

1
使用TDE进行数据库镜像
我需要镜像一些数据库,并在它们上使用透明数据加密(TDE),因为我们的数据必须在“静止”时进行加密。 我在主体和镜像上都设置了TDE。当我设置两个数据库的镜像时,我遇到了这个问题。由于我使用的是TDE,所以我不知道通过gui设置镜像的方法,因此我不得不使用t-sql来完成工作。 以下是我在镜像服务器上使用的代码 --Restore the full backup to the mirrored mdf and ldf OPEN MASTER KEY DECRYPTION BY PASSWORD = '1Password' RESTORE DATABASE TDE FROM disk = '\\SERVERNAME\SQL_Stuff\Backup\TDE_FULL.bak' WITH NORECOVERY, REPLACE, MOVE 'TDE' TO 'E:\TDE.mdf', REPLACE, MOVE 'TDE_log' TO 'G:\TDE.ldf' CLOSE MASTER KEY GO --Restore the log backup to the …

1
将文件组设置从RESTRICTED_USER更改为MULTI_USER后,为什么我的数据库镜像崩溃了?
我的环境如下: VMWare 5.5充满活力的服务器MS Windows Server 2008R2 Enterprise域和SQL Server 2008 R2 Enterprise。具有光纤通道连接的集中存储。 我的分区中有分区SQL Server DB。我有2个file groups:一个带有实时数据(FG1),第二个带有历史数据(HDG)。 第二个文件组是read-only。每个月我都会在分区中移动-我将新数据(上个月的数据)添加到历史数据中。这个过程是自动的。 我们将数据库移至新服务器。最初,我必须手动执行该过程。在此操作期间,我的镜像发生故障(在操作3之后-参见下面的流程),并出现以下错误: 在主要服务器上: 日志中的行0: Date 15.6.2015 20:54:11 Log SQL Server (Current - 16.6.2015 07:55:00) Source spid84 Message Setting database option MULTI_USER to ON for database MYDB. 日志中的第1行: Date 15.6.2015 20:54:11 Log SQL Server (Current - …

1
我可以在镜像数据库上收缩事务日志文件吗?
这是先前问题的后续问题,该问题为何我无法缩小主体数据库上的日志文件。 简而言之,我设置了数据库镜像,但是忘记确保备份事务日志的作业再次运行,并且事务日志增长到将近60GB。 由于已建立镜像,因此在镜像服务器上重复进行了此大小增加,最终占用了所有磁盘空间,并使镜像数据库不可用。 每这一问题有关镜像数据库事务日志的维护,你不能备份日志上镜,但是当在特别要求评论有关如何收缩镜像数据库上一个杂草丛生的日志文件,一个注释中留下了 一种方法是将故障转移到镜像数据库并在该数据库上进行收缩。在非生产环境中进行彻底测试,以确保它具有您想要/期望的行为。 这似乎表明可能还有其他方法可以将镜像文件收缩到镜像上,并且这种方法在生产服务器上不一定是安全的。 有没有办法安全地缩小数据库镜像上的事务日志文件?

1
破坏和还原镜子
我必须在镜像的辅助节点上进行一些维护。由于这是站点变慢的结果,而在短暂的网络中断后重新建立镜像时,我想确保安全并禁用该镜像,然后在完成对有问题的服务器的拨入操作后重新启用它。 我目前的计划是: 禁用镜子 进行潜在的危险故障排除 恢复所有丢失的事务日志 重新建立镜子 这是断开/重新建立镜像的最安全方法吗?有什么我应该注意的陷阱吗?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.