标签: replication

有没有一种方法可以测量 MySQL 中的复制延迟，分辨率小于 1 秒？

也就是说，可以在微秒或毫秒级别上测量复制延迟吗？

参考数据库的复制和复制之间有区别吗？

我不确定我是否完全正确，但复制对我来说意味着我们在不了解数据的情况下一点一点地复制，而复制更像是逻辑复制，我们在数据库级别进行复制。我对么？

还有更多的复制和复制吗？

我在两个 SQL Server 2008 SP1 服务器之间有一个事务复制，它们都在 Windows 2003 Server 上。发现主库和订阅库的部分表存在差异。我已经对记录计数进行了手动验证，并且存在细微差异。我知道双方之间存在延迟，所以不用太担心，但是有一个特定的表无论如何都不会同步（新行出现，但一些特定的旧行没有出现，所以它们看起来像同步后删除）。

情况是订阅数据库不是只读的，因此应用程序可以读取数据，也可以向该数据库写入数据。

现在我想知道您将使用哪些解决方案来同步双方。我现在能想到两个：

• 对每篇文章使用 tablediff.exe 实用程序来比较源表和目标表并生成脚本

• 重新初始化订阅，这样它就会使上一个快照无效并生成一个新快照。

有没有其他解决方案来解决这个问题？

我们的复制从站在运行相对简单的插入时生成了大约 300GB 的临时文件。

我们的设置：
大师：5.0.45-0.sles10.x86_64，

从站：5.0.85-win32，也试过 5.1.57-win64，同样的数据库

从机配置：

MAX_CONNECTIONS = 100
query_cache_size变量= 1M
的table_cache = 2048
tmp_table_size的= 32M
thread_cache_size的= 8
binlog_cache_size = 10M
myisam_max_sort_file_size = 100G
myisam_sort_buffer_size = 69M
的key_buffer_size = 55M
read_buffer_size = 64K
read_rnd_buffer_size = 256K
sort_buffer_size的值= 8M
innodb_additional_mem_pool_size = 16M
的innodb_flush_log_at_trx_commit = 0
innodb_log_buffer_size = 16M
innodb_buffer_pool_size = 512M
innodb_thread_concurrency参数= 10
datadir=D:\MySQLrepl\
innodb_data_home_dir=D:\MySQLrepl\
innodb_data_file_path中= ibdata1中：33266M; ibdata2：31484M; ibdata3：52988M; ibdata4：123492M; ibdata5：100M：自动扩展
innodb_log_group_home_dir = d：\ MySQLrepl \
innodb_log_files_in_group = 2
innodb_log_file_size = 128M
登录斌= MySQL的宾

数据库信息：
~360 GB 总数据大小
~50 …

我在服务器 S1 上有 mysql DB（mysql 版本 5.1.41-3ubuntu12.7-log）。

我在服务器 S2（mysql 版本 5.1.54-1ubuntu4-log）上为这个数据库创建了主从。

S1 上的 DB 使用一个数据文件 (ibdata)。

将数据库转储到 S2 后，我设置了innodb_file_per_table=1. 这使得每个表都有自己的 ibd 文件。现在一切顺利。

在 S2 上重新启动 mysql 后，我遇到了出现此错误的问题：
Error 'Unknown table engine 'InnoDB'' on query. Default database: MyDB 当我尝试显示引擎时，我得到以下信息：

显示引擎；
+------------+---------+------------------------- ------------------------------+------------ ---+------+------------+
| 发动机 | 支持 | 评论 | 交易 | XA | 保存点 |
+------------+---------+------------------------- ------------------------------+------------ ---+------+------------+
| 我的ISAM | 默认 | MySQL 3.23 的默认引擎，具有出色的性能| 否 | 否 | 否 |
| MRG_MYISAM | 是 | 相同 …

我有一个主数据库，其中已经有一些数据。master 数据库中的表包括 MyISAM 和 InnoDB 引擎。现在我想使用mysqldump来转储我的从 MySQL 服务器的初始数据。我应该传递给 mysqldump 的参数是什么？目前我使用的是下面列出的。

mysqldump --host=localhost --user=root --password=pa4word --single-transaction --lock-all-tables --master-data=1 mydb > result.sql

这个命令可以吗？我不知道这是否适合我的环境（MyISAM 和 InnoDB 引擎表在一个数据库中）。

谢谢，

我在主/从配置模式下运行 mysql 服务器。有多个从主从复制。它们工作正常并且它们的复制状态受到监控。

其中一名奴隶为特殊目的服务。开发人员给了我一组要在从属 A 上复制的从属数据库上运行的更新查询。

他们正在更新数据库表中的旧记录（修改大量记录的列数据）。

问题

• 有什么办法可以弄清楚给定的查询是否会破坏复制？
• 对于将来，我如何确定查询是否会破坏复制？

我白痴重新引导用作MySQL从一台机器，而无需运行STOP SLAVE，FLUSH TABLES第一。

我原以为 MySQL 会在机器重启期间自动处理所有这些，但显然它没有，至少在我使用的配置中没有，因为 SLAVE 没有启动备份。

mysqld确实启动了，但日志中有一条错误消息，表明从属部分由于重复的主键问题而停止。这意味着它正在尝试插入已经添加的数据。

以下是mysql日志中产生的错误：

120104 11:07:54 [Warning] Slave: Duplicate entry '94459' for key 'PRIMARY' Error_code: 1062
120104 11:07:54 [ERROR] Error running query, slave SQL thread aborted.
    Fix the problem, and restart the slave SQL thread with "SLAVE START".
    We stopped at log 'mysql1-bin.000362' position 3384732

如何确定进程需要从主二进制日志中的哪个位置开始运行CHANGE MASTER语句？我知道我可能会使用 跳过日志条目，sql_slave_skip_counter但不知道要跳过多少，我需要一个一个地进行，这可能需要一整天。

出于某种原因，我的 PostgreSQL 从站不再流式复制主站上的更改。之前可以用，有段时间了，最​​近发现slave的数据库内容很旧，slave的日志文件有错误，分别是“无效幻数0000 ”和“乱序时间线ID 1（之后2） ”。

你知道我该如何解决这个问题吗？或者为什么会发生？

详情如下。

日志文件错误消息：（在从站上，pg_log/postgresql-Sat.log）

LOG:  entering standby mode
LOG:  redo starts at 0/1C78848
LOG:  consistent recovery state reached at 0/1C7FA30
LOG:  database system is ready to accept read only connections
LOG:  invalid magic number 0000 in log file 0, segment 1, offset 14942208
LOG:  streaming replication successfully connected to primary
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
FATAL:  terminating walreceiver process due to administrator …

众所周知，从 MySQL 5.1.12 到 MySQL 5.1.28 的默认混合模式复制。然而，这被恢复了，并且在当前时刻，基于语句的复制是默认的。

在声明默认基于语句的复制中，Oracle声称这只是因为混合模式复制构成了一种行为改变，可能会引起一些用户不知道。（另请参阅Bug 39812。）然而，MySQL 5.1 有许多行为变化，因为混合基复制的好处如此明显（我相信每个 DBA 都遇到过复制失败的情况，因为用户提交了一个查询没有正确复制并导致他们的数据库出现分歧），这似乎不是一个特别有力的理由。

有一些人抱怨混合复制“可以提供两全其美，但需要测试”，但我们已经在 MySQL 5.1.61 上，人们希望现在所有错误都已解决。所以这让我们很困惑。为什么混合模式复制不是默认的？