mysql - master 主复制 MySQL 性能

Question

我目前在 16 核 60gig ram 服务器上有一个 MySQL 实例。该实例根据我们网站和应用程序的流量不断接收大量插入和更新。问题是当报告运行或繁重的 crons 时，这会导致服务器挣扎并且插入开始达到锁定超时。

我看过集群，但我认为这对我们来说太先进了。我想澄清一些关于主-主复制概念的问题(2x 16core 60gig)。

1) 我可以使用一个 master 进行写入和更新，而另一个进行大量读取吗？这是否有助于解决我的性能问题？

2) 如果一个 master 宕机，另一个 master 是否继续运行，此外，当宕机的 master 恢复在线时，它是否从另一个 master 恢复丢失的事务？

3) 我可以运行 4 个 master，其中 2 个作为另外 2 个的故障转移吗？

非常感谢任何帮助。

Answer 1

我猜你不需要 1 年后的答案，但只需要其他有类似问题的人。

我们使用一个主服务器进行大量更新 + 3 个副本用于从我们的应用程序中进行大量读取。

复制非常稳健。如果主服务器在短时间内无法访问(有时也是由于网络问题)，则副本会在主服务器再次启动后重新同步。

如果某个副本死亡或长时间无法访问， future 的同步取决于它“死亡”的时间。对于副本能够同步主必须有旧的二进制日志仍然存在。如果它们已被删除，您将不得不重新创建副本。 (如果所有副本都无法访问 master 但正在运行和接收更新，这也可能是一个问题。所以不要试图在磁盘容量上省钱......)

masters+replicas越多越好。您可以将更新 fork 到更独立的母版。或者将主服务器设置为主服务器复制 - 效果很好我用了一段时间。

如果经常出现网络问题，我建议修改设置 - 请参阅此处 - http://mysql.freeideas.cz/subdom/mysql/2016/08/16/mysql-replication-troubleshooting-lags-on-replicas/

我强烈建议在 prometheus + grafana 和 mysql_exporter ( https://github.com/prometheus/mysqld_exporter ) + Percona 仪表板 ( https://github.com/percona/grafana-dashboards) 中使用监控。它允许您实时查看复制延迟，新的 Grafana 4.0 甚至允许您对其设置警报。让您的生活更轻松 :-)