标签: replication

自从它设置以来，我第一次需要重新启动只读的 MySQL 复制从属设备。

我找到了这篇关于关闭从属设备进行维护的文章（尽管他只是在描述停止mysql守护进程）：

如何安全地[原文如此] 重新启动您的 MySQL 从属服务器

概括起来，程序是：

在mysql客户端：

STOP SLAVE;
FLUSH TABLES;

从操作系统：

/etc/init.d/mysql stop

我会在此时重新启动，然后在系统启动后：

在mysql客户端（mysql守护进程被配置为在启动时启动）：

START SLAVE;

这看起来对吗？还有什么我应该做的吗？

我有一个 master -> slave 配置，其中 master 失败了。我已经能够将旧奴隶重置为主人，并将旧主人重置为奴隶。美好的。

我似乎无法做的是删除旧从机上的主信息，现在是新主。我懂了：

mysql> show slave status \G
*************************** 1. row ***************************
           Slave_IO_State: 
              Master_Host: 10.1.2.101
              Master_User: replicationSlave
              Master_Port: 3306
              ...
              Slave_IO_Running: No
              Slave_SQL_Running: No

我已经阅读了很多MySQL 文档，但我仍然没有找到一种方法来清除 new-master 中的 slave 信息。我试过了：

1. RESET SLAVE这似乎没有清除这些设置。[[实际上它确实删除了master.info文件，但没有删除内存设置。见下文。]]
2. CHANGE MASTER TO MASTER_HOST='' 由于它最近被弃用，它只是吐出一个错误。
3. 检查my.cnf哪些没有主信息，因为它们是以编程方式添加的。
4. RESET MASTER因为一些 mysql 文档推荐了它。那只会重置 bin 日志。
5. 在内部 MySQL 表中查看是否可以找到要清除的字段。

在 MySQL ~5.5.9 上执行此操作的正确方法是什么？谢谢你的帮助。

编辑：

所以事实证明，正如@RolandoMySQLDBA 暗示的那样，RESET SLAVE删除了该master.info文件。但是，在删除从站信息之前，您仍然需要重新启动服务器。

有什么办法不用重启mysqld就可以去掉这个slave信息吗？

我正在使用 MySQL-5.1.50 和主从复制设置。

大多数情况下，slave 落后于 master。

当我运行时show processlist;，没有需要很长时间的查询。我也启用slow_log了。但是，它没有发现任何运行缓慢的查询。

从站不断发出警报，指出复制落后于主站几秒钟。有时，滞后时间会增加。

如何诊断问题的原因？

我需要紧急帮助，因为这个问题已经持续了 20 天。

我正在查看两台服务器之间的快照复制。这是我所拥有的：

• 500GB 数据库
• ~500MB 每晚 bcp 负载
• ~50MB 每日交易量

我向公司中的其他 DBA 询问要使用哪种复制类型。有人告诉我使用快照复制。但是，据我了解和阅读，每天晚上加载后快照都会将数据库完全复制到分发服务器，然后完全覆盖其他服务器。

快照是在增量中工作还是每次都是完整的副本？

我有一个测试环境，设置如下：

• 虚拟机 (Hyper-V)
• Windows Server 2008 R2 SP1（x64 位）
• Windows SQL Server 2005 Developer Edition SP4（x64 位）（默认实例名称）
  • 1 个带有合并复制的数据库设置... 3 个出版物，每个出版物有 2 个订阅者。

我们正在测试升级到 SQL Server 2012 Developer Edition (sp1) 的过程...

我已经下载了 64 位 SQL Server 2012 Dev 的 iso。(sp1) 来自 MSDN（完整许可副本），并已开始走上升级之路。在开始检查不同标准的最后阶段之一，我们遇到了一个奇怪的问题，如下所述：

Rule "Upgrade architecture mismatch" failed. The CPU architectures of upgrading feature(s) are different. To upgrade these features, Setup architecture must be the same as the features being installed.

此外，在升级日志文件中，我发现了以下（更详细的）输出：

(03) 2012-12-28 14:02:45 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.BlockMixedArchitecture …

你能帮我理解为什么我在完全重新同步后在从服务器上收到“主键的重复条目”。

基本上'mysqldump'几乎整晚都在运行，然后恢复过程花了几个小时，所以当我启动slave时，它比master慢了~63874秒。

从服务器是只读的（read_only）并且在重新同步过程中没有任何写入，所以我不明白为什么会有重复的密钥。

二进制日志格式在 master 上设置为 MIXED。

用于备份数据库的命令：

mysqldump --opt --single-transaction -Q --master-data=2 db | bzip2 -cz > db.sql.bz2

从站仅从主站（db -> db_backup）复制一个数据库，并使用以下选项：

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

MySQL Server 1 作为主服务器运行。
MySQL Server 2 作为 Slave 运行。

两个数据库都在线时，它们处于“完美同步”状态。如果Slave下线，Master还在线没有问题；一旦 Slave 再次在线，它们将恢复同步。

除了服务器配置之外，如果主服务器脱机，我会重定向从数据库的连接（使用 JSP 代码）（我当然用 /etc/init.d/mysqld stop 进行了测试）。

当Master重新上线时，有没有自动同步Master和Slave更新的方法？

我们有一个位于不同数据中心的vanilla master 和slave MySQL 设置，以及与master 位于同一数据中心的另一个slave。

数据中心之间的带宽相当高（在我们所做的网络基准测试中，我们可以达到 15MB/秒），但存在延迟，约为 28 毫秒。无论如何它都不高，但它比同一数据中心的亚秒延迟要高得多。

有时，我们会在删除从站时遇到严重的滞后（2000 秒甚至更多），而本地从站保持最新。在查看滞后的远程slave时，SQL线程通常会花时间等待IO线程更新中继日志。主人同时显示“等待网络”或类似的东西。

所以这意味着它是网络，但在发生这种情况时我们仍然有免费带宽。

我的问题是：数据中心之间的延迟会影响复制的性能吗？从属 io 线程是否只是流式传输事件直到主节点停止发送它们，还是在事件之间以某种方式池主节点？

我有一个 SQL Server 2008 R2 服务器，其中包含一堆当前在兼容级别 90 (2005) 下运行的已发布数据库。

订阅数据库也是 SQL Server 2008 R2，但是目标数据库设置为兼容性级别 100，并且复制工作正常。

如果我更改已发布数据库的兼容性级别，它会以任何方式影响复制，还是只是重新初始化所有订阅并重新启动复制的情况？

我怀疑更改已发布的数据库兼容性级别可能会稍微改变复制存储过程的功能，但我不是 100% 确定。

是这种情况吗？

有时，MongoDB 中的操作会失控，最终可能会运行数百秒，并影响性能，直到它们被终止或完成。

发生这种情况时，我知道我可以killOp()使用，但是如何仅终止有针对性的长时间运行的操作而不终止（例如）复制中涉及的长时间运行的操作（这可能很危险）？