bar*_*lay 3 mysql replication trigger timestamp mysql-5.5
我们正在使用 MySQL。我们有一个 master,最终会有 2 个 slave。当某些表中的数据发生变化时,数据库中有触发器会执行。我想知道是否禁用奴隶中的触发器。在我看来,我应该。似乎应该在从站中禁用时间戳之类的东西,否则从站上的数据将与主站上的数据不同。
我不是 DBA,我是开发人员。我们公司没有 DBA,所以运营管理员和我正在解决这个问题。我们已经设置并复制了主站和一个从站,我们在从站上遇到了重复输入错误。
我们正在考虑不要因为重复的复制错误而停止复制,如这篇文章所示:http : //www.ducea.com/2008/02/13/mysql-skip-duplicate-replication-errors/。我们不知道这是否是个好主意。我确实觉得这掩盖了问题,但我们都不知道如何解决问题。
如果我们应该禁用触发器和/或设置从属设备不插入时间戳,我们该怎么做?还是将 db 建立为从站会自动执行这些操作?
不要禁用从站上的触发器,也不要将您的从站配置为跳过错误。
当使用一致的数据集和相同的配置(包括表及其数据、视图、触发器、存储函数和存储过程)正确设置复制时,它就可以正常工作。如果它不是“只是工作”,那么它已经在这些方式之一中不一致。重复的键错误是一个危险信号,表明您的数据不相同,您不想抑制这一点。
如果你还没有,你应该使用binlog_format=MIXED除非你有特定的理由不这样做。MySQL 5.6 之前的默认值是,STATEMENT但这主要是出于遗留原因。
使用混合日志记录允许 master 上的优化器选择最好的方式来记录对 master 数据的每个更改——或者通过:
如果一个语句被确定为基于语句的日志记录是“不安全的”(意味着它可能会导致数据与其初始相同状态不同),如果您使用MIXED模式,它将自动记录为基于行的记录。这方面的例子是涉及对非确定性函数的调用的语句,例如UUID()在 master 和 slave 上返回不同的值。基于行的日志可以毫无问题地处理这个问题,因为它传递了文字值。
你可能认为 NOW()也可能是这样一个函数,如果服务器时钟不同步,类似的限制可能适用于自动时间戳列,但事实并非如此——因为对于每个二进制(复制)日志条目,主服务器记录它的内容当前时间戳是执行查询时的时间戳——允许从站拥有一个“伪系统时钟”,以便在需要时执行该语句时实际捏造主站时钟的值。顺便说一句,这个日志条目是从服务器通过将其系统时钟与记录的时间戳进行比较来计算“落后于主服务器的秒数”的方式。(例外情况是当从服务器执行了其中继日志中的所有内容时,它始终显示“0”秒后,因为它没有
如果使用基于行的日志记录查询,则触发器更改的任何数据也将记录为基于行的日志条目,并且从站上的触发器将不会自动触发。
另一方面,如果使用基于语句的日志记录来记录相同的查询,那么复制取决于从属服务器上存在的相同触发器,因为主服务器不会记录触发器所做的事情——它只记录发出的查询,并且假设您希望所有服务器上的数据保持一致,则取决于从属触发器的触发与它们在主服务器上完全一样。
使用基于语句的复制,在主服务器上执行的触发器也会在从服务器上执行。使用基于行的复制,在主服务器上执行的触发器不会在从服务器上执行。相反,由触发器执行导致的主服务器上的行更改被复制并应用于从服务器。
此行为是设计使然。[...]
http://dev.mysql.com/doc/refman/5.5/en/replication-features-triggers.html
该文档通常以听起来像要么/或(语句或行)的术语谈论复制,但对于每个查询执行的MIXED日志记录将在每个查询的基础上选择日志记录方法。您可能还会发现在某些情况下“需要”基于行的日志记录的语句,但这仅意味着它必须可用(即,通过MIXED);这并不意味着服务器必须配置为ROW. 当然,无论二进制日志格式如何,DDL 始终记录为语句。
| 归档时间: |
|
| 查看次数: |
3837 次 |
| 最近记录: |