有的时候博客内容会有变动，首发博客是最新的，其他博客地址可能会未同步,认准https://blog.zysicyj.top
首发博客地址[1]
参考视频[2]
MMM 方案（单主）
MySQL 高可用方案之 MMM（Multi-Master Replication Manager）是一种常用的解决方案，用于实现 MySQL 数据库的高可用性和负载均衡。
MMM 基于 MySQL 的复制机制，通过在多个 MySQL 实例之间进行主从复制，实现了数据的同步和备份。它的主要特点是可以实现多主复制，即多个 MySQL 实例可以同时作为主节点接收写操作，并将这些写操作同步到其他从节点上。
MMM 的工作原理如下：
- MMM 通过监控 MySQL 实例的状态来实现故障检测和自动故障转移。当一个主节点发生故障时，MMM 会自动将其中一个从节点提升为新的主节点，确保数据库的可用性。
- MMM 还可以根据负载情况自动进行负载均衡。它可以根据每个节点的负载情况，将读操作分发到不同的节点上，从而提高系统的整体性能。
- MMM 还提供了一些管理工具，可以方便地进行节点的添加、删除和配置修改等操作。
使用 MMM 可以有效地提高 MySQL 数据库的可用性和性能。然而，需要注意的是，MMM 并不能解决所有的高可用问题，例如**网络分区和数据一致性 **等问题。在实际应用中，还需要结合其他技术和方案，如数据库集群、数据复制和数据备份等，来构建更完善的高可用架构。
MMM 作为 MySQL 高可用方案，具有以下优点和缺点：
优点：
- 高可用性：MMM 通过自动故障检测和故障转移机制，可以快速将一个从节点提升为新的主节点，从而实现数据库的高可用性，减少系统的停机时间。
- 负载均衡：MMM 可以根据节点的负载情况，将读操作分发到不同的节点上，从而实现负载均衡，提高系统的整体性能。
- 简单易用：MMM 提供了一些管理工具，可以方便地进行节点的添加、删除和配置修改等操作，使得系统的管理和维护变得简单易用。
缺点：
- 数据一致性：由于 MMM 采用的是异步复制机制，主节点和从节点之间存在一定的延迟，可能导致数据的不一致。在某些场景下，可能需要额外的措施来确保数据的一致性。
- 单点故障：虽然 MMM 可以自动进行故障转移，但在故障转移过程中，可能会存在一段时间的数据库不可用。如果 MMM 本身发生故障，可能会导致整个系统的不可用。
- 配置复杂性：MMM 的配置相对复杂，需要对 MySQL 的复制机制和 MMM 的工作原理有一定的了解。在配置过程中，需要注意各个节点的配置一致性和正确性。
http://blog.zysicyj.top/mysql_mmm
MHA 架构（单主）
架构图
MySQL MHA（Master High Availability）是一种用于 MySQL 数据库的高可用性架构。它的设计目标是确保在主数据库发生故障时，能够快速自动地将备库（Slave）提升为新的主库，以保证系统的连续性和可用性。
MHA 架构由以下几个核心组件组成：
- Manager 节点：Manager 节点是 MHA 的核心组件，负责监控主库的状态并自动执行故障切换操作。它通过与 MySQL 主库和备库建立 SSH 连接，实时监测主库的状态，并在主库发生故障时触发自动故障切换。
- Master 节点：Master 节点是 MySQL 数据库的主库，负责处理所有的写操作和读操作。MHA 会通过与 Master 节点建立 SSH 连接，实时监测主库的状态。
- Slave 节点：Slave 节点是 MySQL 数据库的备库，负责复制主库的数据。MHA 会通过与 Slave 节点建立 SSH 连接，实时监测备库的状态。
MHA 的工作流程如下：
- Manager 节点通过 SSH 连接与 Master 节点和 Slave 节点进行通信，实时监测它们的状态。
- 当 Manager 节点检测到 Master 节点发生故障时，它会自动将一个备库提升为新的主库。
- 在故障切换期间，Manager 节点会自动更新应用程序的配置文件，将新的主库信息通知给应用程序。
- 一旦新的主库上线，Manager 节点会自动将其他备库重新配置为新的主库的从库，并开始复制数据。
MHA 架构的优点包括：
- 自动故障切换：MHA 能够自动检测主库的故障，并快速将备库提升为新的主库，减少了手动干预的需要，提高了系统的可用性。
- 实时监测：MHA 通过与 Master 节点和 Slave 节点建立 SSH 连接，实时监测它们的状态，能够及时发现故障并采取相应的措施。
- 简化配置：MHA 提供了简单易用的配置文件，可以轻松地配置主库和备库的信息，减少了配置的复杂性。
- 高可扩展性：MHA 支持多个备库，可以根据需求灵活地扩展系统的容量和性能。
MHA 架构虽然有很多优点，但也存在一些潜在的缺点：
- 配置复杂性：尽管 MHA 提供了简化的配置文件，但对于不熟悉 MHA 的用户来说，配置仍然可能是一项复杂的任务。特别是在涉及多个主库和备库的复杂环境中，配置可能变得更加困难。
- 依赖 SSH 连接：MHA 使用 SSH 连接与主库和备库进行通信和监控。这意味着在配置和使用 MHA 时，必须确保 SSH 连接的可用性和稳定性。如果 SSH 连接出现问题，可能会导致 MHA 无法正常工作。
- 故障切换过程中的数据同步延迟：在故障切换期间，MHA 需要将备库提升为新的主库，并重新配置其他备库作为新的从库。这个过程可能需要一些时间，导致在切换期间存在一定的数据同步延迟。这可能会对某些应用程序的数据一致性产生影响。
- 依赖 MySQL 复制功能：MHA 依赖 MySQL 的复制功能来实现数据的同步和复制。如果 MySQL 的复制功能出现问题，可能会导致 MHA 无法正常工作或数据同步不完整。
- 需要额外的硬件资源：为了实现高可用性，MHA 需要至少一个备库来作为冗余备份。这意味着需要额外的硬件资源来支持备库的运行和数据复制，增加了系统的成本和复杂性。
需要注意的是，MHA 并不是万能的解决方案，它适用于大多数的 MySQL 数据库场景，但在特定的情况下可能需要根据实际需求进行定制化的配置和调整。此外，为了确保 MHA 的正常运行，还需要进行定期的监控和维护工作，以保证系统的稳定性和可靠性。
MGR 架构（单/多主）
MGR（MySQL Group Replication）是 MySQL 官方提供的一种高可用性架构，用于实现 MySQL 数据库的主从复制和自动故障切换。MGR 基于 MySQL 的 InnoDB 存储引擎和 Group Replication 插件，通过使用多主复制的方式来提供高可用性和数据一致性。
MGR 架构的核心组件包括：
- Group Replication 组件：Group Replication 是 MySQL 官方提供的插件，用于实现多主复制和自动故障切换。它基于 Paxos 协议，通过在集群中的成员之间进行通信和协调，实现数据的同步和一致性。
- Primary 节点：Primary 节点是 MGR 集群中的主节点，负责处理所有的写操作和读操作。Primary 节点接收来自应用程序的写请求，并将数据复制到其他节点（Secondary 节点）上。
- Secondary 节点：Secondary 节点是 MGR 集群中的从节点，负责复制 Primary 节点上的数据。Secondary 节点通过与 Primary 节点进行通信，接收并应用 Primary 节点上的写操作，以保持数据的一致性。
MGR 架构的工作流程如下：
- 初始化集群：在 MGR 架构中，首先需要选择一个节点作为初始 Primary 节点，并将其配置为 Group Replication 组件的成员。然后，其他节点可以加入到集群中，并通过与 Primary 节点进行通信，获取数据并成为 Secondary 节点。
- 数据同步：一旦集群初始化完成，Primary 节点开始接收来自应用程序的写请求，并将数据复制到其他节点上。Secondary 节点通过与 Primary 节点进行通信，接收并应用 Primary 节点上的写操作，以保持数据的一致性。
- 自动故障切换：如果 Primary 节点发生故障，Group Replication 组件会自动选择一个 Secondary 节点作为新的 Primary 节点，并将其他节点重新配置为新的 Secondary 节点。这个过程是自动的，无需人工干预。
MGR 架构的优点包括：
- 自动故障切换：MGR 能够自动检测 Primary 节点的故障，并快速将一个 Secondary 节点提升为新的 Primary 节点，实现自动故障切换，提高了系统的可用性。
- 数据一致性：MGR 使用 Paxos 协议来保证数据的一致性。在写操作提交之前，集群中的成员会达成一致，确保数据在所有节点上的复制是一致的。
- 简化配置和管理：MGR 提供了简单易用的配置选项和管理工具，使得集群的配置和管理变得更加简单和方便。
- 高可扩展性：MGR 支持多主复制，可以根据需求灵活地扩展系统的容量和性能。
需要注意的是，MGR 架构也有一些限制和注意事项：
- 网络稳定性：MGR 对网络的稳定性要求较高，因为节点之间需要进行频繁的通信和数据同步。如果网络不稳定，可能会导致数据同步延迟或节点之间的通信故障。
- 数据冲突：由于 MGR 支持多主复制，如果应用程序在不同的节点上同时进行写操作，可能会导致数据冲突和一致性问题。因此，需要在应用程序层面进行合理的设计和处理。
- 配置复杂性：尽管 MGR 提供了简化的配置选项和管理工具，但对于不熟悉 MGR 的用户来说，配置仍然可能是一项复杂的任务。特别是在涉及多个节点和复杂环境中，配置可能变得更加困难。
在使用 MGR 之前，建议进行充分的测试和评估，以确保它能够满足系统的可用性和性能要求，并根据具体的应用场景和需求进行适当的配置和调整。
