百战--海量数据存储与查询 数据库中间件Mycat

avatar
Administrator

2024-09-09

29
0

数据库中间件Mycat

什么是Mycat

Mycat是数据库中间件，所谓中间件数据库中间件是连接Java应用 程序和数据库中间的软件。

Mycat 是一种开源的数据库中间件，它的主要作用是提供分库分表、读写分离等功能，使得应用程序能够处理更大规模的数据库访问需求。

具体来说，Mycat 是一种 数据库代理层，它位于应用程序和底层数据库之间，负责分发 SQL 请求、合并结果集等。通过 Mycat，开发者可以将数据分布在多个数据库实例中（分库分表），实现水平扩展，提升数据库系统的性能和可用性。Mycat 主要解决以下几个问题：

1. 分库分表：对于大数据量的系统，可以将数据分布在多个数据库实例中，减轻单一数据库的压力。

2. 读写分离：Mycat 支持主从数据库架构，将写操作发往主库，将读操作发往从库，提升数据库的并发处理能力。

3. 高可用性：通过主从切换和故障恢复机制，Mycat 可以帮助系统实现高可用性。

4. 跨数据库操作：Mycat 可以在不同的数据库之间执行查询，并对结果进行合并。

Mycat 支持的数据库包括 MySQL、PostgreSQL、Oracle 等，因此它可以作为不同类型数据库的统一访问入口。

为什么要用Mycat

遇到问题： Java与数据库的紧耦合 高访问量高并发对数据库的压力 读写请求数据不一致

针对遇到问题：

Java与数据库的紧耦合 高访问量高并发对数据库的压力 读写请求数据不一致遇到的问题，Mycat 可以提供有效的解决方案：

1. Java与数据库的紧耦合

Java 应用与数据库的紧耦合问题，通常是由于直接操作数据库，导致数据库结构变更或扩展时对应用程序的影响较大。Mycat 通过提供一个数据库中间件层，可以降低 Java 应用与数据库的耦合度。具体方式如下：

  • 解耦应用与数据库：Mycat 作为代理层，屏蔽了底层数据库的分片、主从复制等细节。Java 应用只需与 Mycat 交互，数据库的扩展和变更可以通过调整 Mycat 的配置文件来完成，而无需对应用程序做大规模修改。

  • 支持多种数据库：Mycat 支持 MySQL、PostgreSQL、Oracle 等不同类型的数据库。应用程序无需关心底层数据库类型的差异，Mycat 提供了统一的接口。

2. 高访问量高并发对数据库的压力

当系统的访问量和并发请求较高时，单个数据库难以承受巨大的负载，导致性能瓶颈。Mycat 通过以下机制缓解数据库的压力：

  • 分库分表：Mycat 可以将数据水平分片（sharding），将请求分发到多个数据库实例上进行处理。通过分库分表，单个数据库只处理部分数据，极大减少了单库的读写压力。

  • 读写分离：Mycat 支持将读请求和写请求分开处理。写操作发送到主库，读操作发送到从库。这样能够在保持数据一致性的前提下，通过从库承担更多读请求，从而提升系统的并发处理能力。

3. 读写请求数据不一致

读写不一致是常见问题，通常由于数据库的主从复制延迟，或者缓存机制导致。这在高并发场景下尤为显著，可能导致用户在写入新数据后马上读取时无法获取到最新结果。Mycat 提供了多种机制来处理这种一致性问题：

  • 强制主库读取：对于某些关键请求，Mycat 可以配置强制从主库读取数据，确保数据的实时性。这样在需要严格一致性的场景中可以保证数据的准确性。

  • 事务一致性：Mycat 支持跨库事务和分布式事务，保证在多库操作中事务的一致性。即使在分片数据库中，也可以通过 Mycat 实现 ACID 特性。

  • 读写分离策略配置：根据业务需求，可以配置不同的读写分离策略。比如，Mycat 可以设置写操作后短时间内的读请求强制发往主库，避免从库延迟导致的数据不一致。

总结：

  • 通过 Mycat 的 解耦特性 解决 Java 与数据库的紧耦合问题，方便底层数据库扩展和演进。

  • 通过 分库分表 和 读写分离 缓解高并发对数据库的压力，提升整体性能。

  • 通过 读写一致性策略 和 事务机制 来解决读写数据不一致的问题。

这些机制能够有效改善你目前面临的挑战，提升系统的扩展性和稳定性。

使用 Mycat 主要是为了应对大型互联网应用在数据库层面上的性能和扩展性问题。具体原因如下：

1. 分库分表应对大数据量

当单个数据库的容量或性能无法满足业务需求时，Mycat 通过分库分表将数据分布到多个数据库实例中，实现水平扩展。这种分片机制可以有效降低单个数据库的负载压力，提升整体的存储能力和查询效率。

2. 读写分离提升性能

在大多数业务场景下，读操作的频率远高于写操作。Mycat 支持读写分离，将写操作发送到主库，读操作发送到从库，从而减轻主库的压力，提升数据库的并发处理能力。这对提高系统响应速度和稳定性非常重要。

3. 高可用性和容灾

Mycat 通过主从切换和故障恢复等机制，保障了数据库的高可用性。一旦某个数据库出现故障，Mycat 能自动将请求路由到其他正常工作的节点，确保系统的稳定运行。

4. 统一管理多种数据库

在一些业务场景中，企业可能会使用不同种类的数据库。Mycat 作为数据库中间件，可以对不同数据库类型进行统一管理，屏蔽底层数据库的差异，简化应用开发。同时，它支持跨数据库的事务操作和查询，使得系统集成更加方便。

5. 减少数据库迁移的复杂性

随着业务增长，数据库从单机架构扩展到分布式架构，直接迁移到分布式数据库方案（如 HBase、Cassandra 等）可能过于复杂。Mycat 提供了一种渐进式的数据库扩展方案，允许开发者在已有关系型数据库的基础上，通过分库分表和读写分离实现扩展，降低了迁移的复杂性和成本。

6. 降低开发难度

Mycat 通过提供代理层，将分库分表、读写分离等逻辑从应用程序中分离出来，开发者无需在业务代码中处理数据库扩展问题。这极大降低了开发的复杂度，让业务开发人员可以更加专注于业务逻辑本身。

7. 支持分布式事务和分布式查询

Mycat 支持跨数据库实例的分布式事务和分布式查询，这意味着即使数据被分片到不同的数据库实例，Mycat 也能够处理复杂的 SQL 查询和保证事务的一致性。

总的来说，Mycat 适用于那些数据量较大、业务发展迅速、并发读写需求较高的系统，帮助解决数据库瓶颈，提升系统的性能、可扩展性和可用性。

Mycat 技术主要解决 高访问量高并发对数据库的压力 问题。

通过 Mycat 提供的分库分表、读写分离、高可用性等功能，它能够有效应对大规模访问和高并发场景下数据库的性能问题，减少单点数据库的压力，并提升系统的扩展能力和稳定性。

Mycat是一个开源的分布式数据库代理层，也被称为MySQL集群，但它并不存储数据，而是通过SQL解析和路由等功能，将客户端的请求分发到后端不同的数据库节点上。以下是Mycat提供的一些关键功能：

  1. 分库分表：Mycat可以根据一定的规则（如取模运算）将大表的数据分散到多个不同的数据库表中，从而实现水平拆分，这样可以提高查询效率，降低单一数据库的压力。

  2. 读写分离：Mycat支持配置主从架构中的多个只读副本，可以将查询请求分发到不同的从库，写操作则通常路由到主库，以此来平衡负载，提高数据库的读取能力。

  3. 高可用性：通过配置多个数据源，Mycat可以在某个数据源出现故障时自动切换到其他正常的数据源，保证服务的连续性。

  4. SQL拦截与优化：Mycat具备一定的SQL拦截功能，可以在一定程度上优化SQL语句，防止一些不当的操作直接作用于数据库，保护后端数据库的安全性和稳定性。

  5. 平滑扩容：随着业务的增长，可以通过添加更多的数据库实例或硬件资源来扩展系统的能力，而不需要改变应用程序逻辑，因为Mycat隐藏了底层数据库的实际分布情况。

通过上述功能，Mycat使得开发人员能够在不修改业务代码的情况下，轻松地管理和扩展数据库集群，以应对不断增长的数据访问需求。

Mycat概述_Mycat与其他中间件区别

Mycat 概述

Mycat 是一款开源的数据库中间件，主要用于解决大规模数据库系统中的性能、扩展性和高可用性问题。它通过提供分库分表、读写分离、跨数据库访问等功能，将应用程序和底层数据库系统解耦，帮助系统在面对大数据量、高并发场景时保持稳定和高效。

Mycat 的核心功能包括：

  • 分库分表：将大规模数据分布到多个数据库实例，减少单库压力，支持水平扩展。

  • 读写分离：将读操作分发到从库，写操作分发到主库，提高并发处理能力。

  • 高可用性：提供主从切换、自动容灾等机制，保障数据库的高可用性。

  • 跨数据库查询：支持在多个数据库之间进行数据查询，并对结果进行自动合并。

Mycat 与其他中间件的区别

这张图展示了 数据库中间件 的一些常见实现，以及它们的背景和特点。图中主要提到了以下几种数据库中间件：

1. Cobar

  • 背景：由阿里巴巴团队开发。

  • 现状：已多年无维护更新。

  • 特点：早期的数据库中间件，可能性能上有些不足，且由于长期未更新，无法适应当下业务需求。

2. Mycat

  • 背景：基于 Cobar 的二次开发，由开源社区维护。

  • 现状：Mycat 社区活跃度非常高，依赖开源社区的不断迭代和更新，吸引了许多开发者和企业使用。

  • 特点：提供分库分表、读写分离等功能，是目前国内较为流行的数据库中间件之一。

3. OneProxy

  • 背景：商业中间件。

  • 现状：未开源，具体的使用和性能情况需要通过商业渠道获取。

  • 特点：一般用于需要专业商业支持的企业场景。

4. Kingshard

  • 背景：由 Go 语言开发的开源数据库中间件。

  • 现状：仍在不断完善。

  • 特点：轻量级，性能优越，但相较于 Mycat 等中间件，功能相对较少。

5. Vitess

  • 背景：由 YouTube 在生产环境中使用。

  • 现状：不支持 MySQL 原生协议。

  • 特点：在 YouTube 这种高并发高数据量场景中被验证，但由于不支持 MySQL 的原生协议，使用门槛较高。

6. Atlas

  • 背景：由 360 团队基于 MySQL Proxy 改写。

  • 现状：高并发场景下可能不太稳定。

  • 特点：功能类似于 Mycat，但由于是基于 MySQL Proxy 改写，在性能和稳定性上存在一些限制。

7. MaxScale

  • 背景：由 MariaDB 团队开发的中间件。

  • 现状：与 MariaDB 深度集成，作为其官方的中间件解决方案。

  • 特点：特别适合与 MariaDB 配合使用，提供负载均衡、读写分离等功能。

8. MySQLRoute

  • 背景：MySQL 官方（Oracle 公司）发布的中间件。

  • 特点：官方出品，专为 MySQL 系列数据库优化，可靠性和兼容性有保障。

总结：

  • Mycat 社区活跃度高，使其成为目前国内较为流行的开源数据库中间件。它与其他中间件相比，具有良好的扩展性和活跃的社区支持。

  • 其他中间件如 Vitess 和 MaxScale 等，虽然各自拥有独特的优势，但在特定场景下有不同的使用限制。

图右边的卡通形象是 Mycat 的吉祥物，强调了其社区的高活跃度和用户基础。

1. 与 Sharding-JDBC 的区别

  • 架构层面：Sharding-JDBC 是轻量级的客户端工具库，与应用程序直接耦合，嵌入到应用中运行；而 Mycat 是代理中间件，独立部署在应用与数据库之间。

  • 部署复杂度：Sharding-JDBC 不需要独立的中间件服务，只需在应用程序中集成，部署简单；而 Mycat 需要单独的中间件服务，部署相对复杂。

  • 应用场景：Sharding-JDBC 更适合轻量级的应用场景，不依赖于中间件集群，适合微服务架构；Mycat 更适合对性能要求高的大型分布式系统。

2. 与 TDDL（淘宝分布式数据层）的区别

  • 适用范围：TDDL 是阿里巴巴的分布式数据库访问层，主要为其内部使用和定制化开发，适配阿里系的技术栈。Mycat 则是通用的开源中间件，适用于各种数据库和多种业务场景。

  • 实现机制：TDDL 强调和阿里内部生态的整合，比如与 DRDS 的无缝对接；而 Mycat 更加通用，支持 MySQL、PostgreSQL、Oracle 等多种数据库。

3. 与 DRDS（阿里云分布式关系数据库）的区别

  • 商业 vs 开源：DRDS 是阿里云提供的商业化分布式数据库服务，而 Mycat 是社区驱动的开源项目。

  • 扩展性：DRDS 依托阿里云基础设施，支持弹性伸缩和高可用，而 Mycat 需要用户自行配置和管理，灵活性更强，但运维成本也更高。

  • 运维成本：DRDS 提供完善的云上运维支持，而 Mycat 则需要用户自己处理服务的高可用、容灾等运维工作。

4. 与 ProxySQL 的区别

  • 设计目标：ProxySQL 是专门为 MySQL 提供的高性能数据库代理，旨在提升 MySQL 的性能和可扩展性，而 Mycat 则不仅支持 MySQL，还支持多种数据库。

  • 功能侧重：ProxySQL 更加侧重于数据库连接池管理、负载均衡、查询缓存等优化 MySQL 性能的功能，而 Mycat 更加注重于分库分表和分布式事务等大规模数据管理场景。

总结

Mycat 的核心优势在于它是一个通用型、开源的数据库中间件，适用于多种数据库场景，特别是在大数据、高并发的环境下表现出色。它与其他中间件的区别主要在于部署架构、支持的数据库种类、应用场景和运维成本等方面。

Mycat优势

性能可靠稳定

基于阿里开源的Cobar产品而研发，Cobar的稳定性、可靠性、优秀

的架构和性能以及众多成熟的使用 案例使得MYCAT一开始就拥有一

个很好的起点，站在巨人的肩膀上，我们能看到更远。

强大的技术团队

MyCat现在由一支强大的技术团队维护 , 吸引和聚集了一大批业内

大数据和云计算方面的资深工程师、架构师、 DBA，优秀的团队保 障了MyCat的稳定高效运行。而且MyCat不依托于任何商业公司， 而 且得到大批开源爱好者的支持。

MyCat已经形成了一系列的周边产品,比较有名的是 Mycat-web、

Mycat-NIO、 Mycat-Balance 等,已经形成了一个比较完整的解决方 案,而不仅仅是一个中间件。

高可用性与MySQL读写分离

利用Mycat可以轻松实现热备份，当一台服务器停机时，可以由双机或集群中的另一台服务器自动接管其业务，从而在无须人工干预

的情况下，保证系统持续提供服务。这个切换动作由Mycat自动完成。

高可用性与MySQL读写分离 是 Mycat 的两个核心功能，帮助企业提高数据库系统的稳定性和性能。

1. 高可用性

Mycat 提供了内置的高可用性支持，使得在数据库主节点或从节点出现故障时，系统依然可以持续运行。这是通过以下机制实现的：

  • 热备份：当主数据库发生故障时，Mycat 能自动切换到备用数据库（通常是从库），从而保障服务不中断。

  • 自动切换：Mycat 可以检测数据库节点的状态，当某个节点失效时，Mycat 自动将请求切换到其他正常工作的数据库节点，无需人工干预。

  • 集群支持：Mycat 支持数据库集群架构，确保在多台服务器中分布负载，并在任意节点发生问题时，其他节点能自动接管工作，避免单点故障。

这种 自动故障切换 机制极大提高了系统的可靠性，保证系统在高并发、大访问量的情况下依然能够保持高可用性。

2. MySQL 读写分离

Mycat 提供了强大的 读写分离 功能，通过将读操作和写操作分别分配到不同的数据库节点，以此来提升系统的性能：

  • 写操作：写操作通常需要发送到主数据库进行处理，保证数据的一致性和事务性。

  • 读操作：Mycat 可以将大量的读请求发送到从数据库，从而减轻主数据库的压力。多台从库可以同时处理读请求，大幅提高并发读的性能。

通过这种方式，读写分离使得系统能在保持数据一致性的同时，显著提升读操作的吞吐量，尤其是在读操作频繁的场景下，能有效分散数据库负载。

3. 切换动作自动化

Mycat 能够自动完成主从切换以及读写分离的管理操作，具体表现为：

  • 自动判断节点状态：Mycat 可以通过心跳机制实时监控各个数据库节点的状态，一旦发现主库或从库故障，会立即触发切换。

  • 无缝切换：Mycat 保证在切换过程中，业务不会受到中断，客户端几乎感知不到切换的发生，从而维持服务的连续性。

这种自动化切换和故障处理机制，极大降低了系统运维成本和复杂度，确保即便在高负载或突发故障情况下，系统依然能平稳运行。

总结

通过 Mycat 实现 高可用性 和 MySQL 读写分离，可以有效提升系统的稳定性和性能。在高并发场景下，Mycat 能自动处理数据库节点的切换操作，确保业务连续性，同时大幅提高读操作的并发能力。

注意：

Mycat 的读写分离及自动切换都依赖于数据库产品的主从数据同步。

Mycat 的读写分离及自动切换依赖于数据库产品的主从数据同步，意味着 Mycat 本身并不负责数据的同步工作，而是依赖底层数据库（如 MySQL）来完成主库与从库之间的数据复制和同步过程。

1. 数据库主从数据同步的基本原理

  • 主库（Master）：在主从架构中，所有的写操作（如插入、更新、删除）都首先在主库执行。

  • 从库（Slave）：从库负责接收主库的更新，并保持与主库数据的一致性。它从主库读取更新的事务日志（binlog）来执行相同的操作，从而完成同步过程。

MySQL 的 主从复制 机制是通过异步或半同步的方式实现的：

  • 异步复制：主库不等待从库确认数据同步完成，而是继续处理新的事务。这种方式的优点是性能较好，但在主库崩溃的情况下，可能导致部分数据没有及时同步到从库。

  • 半同步复制：主库在提交事务后，会等待至少一个从库确认同步完成后再继续处理其他事务。这种方式增加了数据一致性的保障，但可能对性能有一定影响。

2. 读写分离依赖数据同步

Mycat 的 读写分离 通过将写请求发送到主库，而读请求发送到从库来实现，但从库上的数据必须与主库保持一致。如果主从数据同步出现问题，如延迟或失败，可能导致从库上的数据与主库不一致，从而出现数据读取不准确的情况。

例如：

  • 用户提交数据写入主库后，立刻进行读取操作。如果从库的同步有延迟，Mycat 可能会从从库返回尚未同步的旧数据。这种现象称为数据延迟，在某些强一致性场景下可能导致问题。

3. 自动切换依赖数据同步

Mycat 的 自动切换 功能允许在主库发生故障时，自动将写请求切换到其他节点（通常是从库）继续处理。然而，这种切换也依赖于主从库之间的数据同步。如果从库的同步延迟很大或未完成同步，切换后可能会导致数据不一致，甚至数据丢失。

例如：

  • 主库发生故障时，Mycat 自动将从库提升为新的主库。如果此时从库尚未同步完所有的数据，切换后的主库数据会与原主库不一致，导致写入新数据后产生数据冲突。

4. 解决数据同步问题的常见措施

为保证 Mycat 读写分离及自动切换的可靠性，通常采取以下措施来减少主从同步带来的影响：

  • 数据同步监控：实时监控主从同步的延迟情况，确保从库的延迟在可接受范围内。如果延迟过大，Mycat 可以避免将读请求分配到该从库。

  • 半同步复制：采用半同步复制机制，确保数据在主库写入后，至少有一个从库成功同步，减少数据丢失或不一致的风险。

  • 强一致性场景优化：在对数据一致性要求较高的场景中，可能需要禁用读写分离，所有的读写操作都在主库上执行，以确保实时性。

总结

Mycat 通过 读写分离 和 自动切换 提升数据库的性能和高可用性，但这些功能的可靠性和准确性高度依赖于底层数据库的 主从数据同步机制。数据库的同步延迟或失败可能影响 Mycat 的行为，因此确保主从同步的稳定性是 Mycat 正常工作的关键。

100亿大表水平分表、集群并行计算

数据切分是Mycat的核心功能，是指通过某种特定的条件，将存放在同一个数据库中的数据分散存放在多个数据库（主机）中，以达

到分散单台设备负载的效果

数据切分有两种切分模式

按照不同的表将数据切分到不同的数据库中，这种切分可以叫作数据的垂直切分。

根据表中数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多个数据库中，这种切分叫作数据的水平切分。当数据量超过800万行且需要做分片时，可以利用Mycat实现数据切分。

数据库路由器

Mycat基于MySQL 实例的连接池复用机制，可以让每个应用最大程度地共享一个MySQL实例的所有连接池，让数据库的并发访问能力

大大提升。

整合多种数据源

当一个项目需要用到多种数据源如Oracle、MySQL、SQL Server、PostgreSQL时，可以利用Mycat进行整合，只需访问Mycat 这一个

数据源就行。

Mycat概念_核心概念详解

逻辑库schema

业务开发人员通常在实际应用中并不需要知道中间件的存在，只需要关注数据库，所以数据库中间件可以被当作一个或多个数据库集

群构成的逻辑库。

逻辑库，与MySQL中的Database（数据库）对应，⼀个逻辑库中定义了所包括的Table。

逻辑表table

既然有逻辑库，就会有逻辑表。在分布式数据库中，对于应用来说，读写数据的表就是逻辑表。逻辑表可以分布在一个或多个分片

库中，也可以不分片。

注意：

Table：表，即物理数据库中存储的某⼀张表，与传统数据库不同，这⾥的表格需要声明其所存储的逻辑数据节点DataNode。

节点主机DataNode

将数据切分后，每个分片节点不一定会独占一台机器，同一台机器上可以有多个分片数据库，这样一个或多个分片节点所在的机器就

是节点主机。为了规避单节点主机并发数量的限制,尽量将读写压力高的分片节点均匀地放在不同的节点主机上。

数据库主机DataHost

数据切分后，每个分片节点(dataNode)不一定都会独占一台机器，同一机器上面可以有多个分片数据库，这样一个或多个分片节点

(dataNode)所在的机器就是节点主机(dataHost),为了规避单节点主机并发数限制，尽量将读写压力高的分片节点(dataNode)均衡的放

在不同的节点主机(dataHost)。

用户

MyCat的用户(类似于MySQL的用户，支持多用户）

在 Mycat 中，逻辑库（schema） 是一个非常重要的核心概念，它将多个物理数据库抽象为一个统一的数据库，方便业务开发人员在实际应用中进行操作，而不需要了解底层中间件或物理数据库的复杂结构。

1. 逻辑库（Schema）概念

Mycat 提供的 逻辑库（schema） 是对多个物理数据库进行抽象和整合后，呈现给用户的一个统一视图。在业务开发中，用户只需要与这个逻辑库进行交互，Mycat 负责将用户的请求路由到正确的物理数据库和表。

  • 隐藏中间件的复杂性：开发人员在操作 Mycat 提供的逻辑库时，与操作单一 MySQL 数据库类似，无需关心数据库中间件的存在，也不需要手动管理底层多个数据库实例的分布或结构。

  • 透明性：Mycat 中的逻辑库对应用程序是透明的，开发者不需要改变应用的数据库连接方式和操作逻辑，只需将原有的数据库连接改为连接到 Mycat 提供的逻辑库。

2. 逻辑库与物理库的关系

Mycat 的 逻辑库（schema） 是多个物理数据库的集合。它通过配置文件中的 schema.xml 和 rule.xml 来定义：

  • schema.xml：描述逻辑库与物理库的对应关系。一个逻辑库可以对应多个物理库，也可以只有一个物理库。

  • rule.xml：定义分库分表的规则，用来决定哪些数据应该存储在哪个物理数据库和物理表中。

例如，一个电商系统中可以有多个物理数据库分别存储用户、订单、商品等信息，但 Mycat 可以将这些物理数据库抽象为一个逻辑库，开发者只需像操作单一数据库一样使用它，而底层的物理数据库和表分配细节由 Mycat 自动处理。

3. 逻辑库的作用与优势

  • 简化业务开发：开发人员只需连接 Mycat 提供的逻辑库，而无需知道后端有多少物理库、分表情况如何，Mycat 自动处理这些复杂的分库分表、读写分离操作。

  • 透明化的扩展：逻辑库的存在使得系统可以很容易进行水平扩展，增加更多的物理数据库来应对数据量的增长，但对上层应用开发者来说是透明的，不需要修改应用逻辑。

  • 负载均衡和容灾：Mycat 可以在多个物理数据库之间分配查询请求，通过读写分离、主从复制和故障切换等机制，保证高并发和高可用性。

4. 实际操作中的逻辑库

业务开发人员通过 SQL 操作 Mycat 提供的逻辑库，Mycat 根据规则自动将请求分发到不同的物理数据库中：

  • 数据写入：Mycat 会根据分库分表规则将写入请求路由到对应的物理库和表。

  • 数据读取：Mycat 会根据读写分离策略，将读请求分发到从库，减轻主库的压力。

  • 数据查询：即使数据分布在多个物理库中，开发人员可以像查询单一数据库一样发送查询请求，Mycat 会自动将请求拆分为多个子查询，并汇总结果返回。

总结

Mycat 中的 逻辑库（schema） 是一种通过中间件对外提供的数据库抽象，它将底层多个物理数据库整合成一个统一的逻辑库，极大简化了业务开发人员的操作复杂度，使得开发者在使用数据库时无需了解底层复杂的分库分表和数据库集群架构。通过 Mycat，逻辑库能够提供透明的分布式数据库管理和读写优化策略，有效提升系统的可扩展性和高可用性。

Mycat技术中逻辑库指的是 与MySQL数据库对应

Mycat技术中逻辑表指的是 物理数据库中存储的某⼀张表

在 Mycat 技术中：

1. 逻辑库：指的是在 Mycat 中定义的一个虚拟的数据库，它对应着一个或多个实际的物理 MySQL 数据库。这种抽象使得 Mycat 可以在多个物理数据库之间进行透明的数据路由和查询分发。

2. 逻辑表：指的是在 Mycat 中定义的一个虚拟的表，它映射到一个或多个物理数据库中的实际表。这种映射使得 Mycat 可以在物理表之间进行查询和数据操作，而对应用程序而言，它只看到逻辑表。

总结来说，逻辑库和逻辑表都是 Mycat 提供的虚拟层，用于将多个物理数据库和表组合成一个统一的视图，简化了数据管理和查询的复杂性。

Mycat概述_Mycat原理

Mycat 的原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的SQL 语句。

对的，Mycat 的工作原理中，“拦截”是一个关键步骤。具体来说，Mycat 作为一个数据库中间件，它会拦截用户发送的 SQL 语句，并根据配置的路由规则和分片策略，将这些 SQL 语句转发到适当的物理数据库和表上。这个过程包括：

1. SQL 解析：Mycat 会解析接收到的 SQL 语句，理解其结构和意图。

2. 路由：根据 SQL 语句的内容（如查询条件、数据表等）以及配置的路由规则，Mycat 确定要将 SQL 语句发送到哪个物理数据库或多个数据库。

3. 分片：对于涉及到数据分片的操作（例如基于某个字段的分片），Mycat 会将 SQL 语句拆分成适合分片的形式，并将其发送到相应的物理表。

4. 结果整合：在处理完 SQL 语句后，Mycat 会将各个物理数据库返回的结果整合起来，并将最终结果返回给用户。

通过这个拦截和处理机制，Mycat 能够实现对数据的透明分布和高效管理。

流程：

首先对 SQL 语句做了一些特定的分析：如分片分析、路由分析、读写分离 分析、缓存分析等，然后将此 SQL 发 往后端的真

实数据库，并将返回的结果做适当的处理，最终再返回给用户

流程示例

  • 1 解析SQL语句涉及的表。

  • 2 查看表的定义，如果表存在分片规则，则获取SQL语句的分片字段。

  • 3 将SQL语句发送到相应的分片去执行。

  • 4 最后处理所有分片返回的数据并返回给客户端。

Mycat部署安装_MySQL主从复制概述

为什么要主从复制

注意：

MySQL是现在普遍使用的数据库，但是如果宕机了必然会造成数据丢失。为了保证MySQL数据库的可靠性。就要会一些提高

可靠性的技术。

如何解决性能问题

生活中有很形象的例子，比如你在自助咖啡厅买咖啡（如果只有一台咖啡机)

如果有多台咖啡机，很明显大家买咖啡的效率就上去了：

MySQL主从复制原理

主从复制的原理则是采用binlog文件进行复制，我们都知道 MySQL的数据库会产生一个二进制日志，就是binlog，该日志 文件记录了数据的任何修改,所以我们的从机Slave会从主机读取 二进制的binlog日志到本机的I/O thread中,然后写入一个Relay log文件中,从机开启一个SQL thread 定时检查Realy log 文件,如 果发现有更新立即把更新的内容在本地的数据库上执行。

MySQL 的主从复制（也称为主从复制）确实是基于二进制日志（binlog）来实现的，以下是主从复制的工作原理：

  1. 主机（Master）：

    • 主机记录所有对数据库的更改操作（如 INSERT、UPDATE、DELETE）到二进制日志（binlog）中。

    • binlog 文件记录了这些操作的详细信息，以便其他服务器可以读取和应用这些操作。

  2. 从机（Slave）：

    • 从机通过 I/O 线程（I/O thread）连接到主机，读取主机上的 binlog 文件。

    • 从机将读取到的 binlog 内容写入到本地的中继日志（Relay log）中。

    • 从机的 SQL 线程（SQL thread）会周期性地检查 Relay log 文件，并将其中的操作应用到本地的数据库中，以保持从机与主机的数据一致性。

这个过程可以分为以下几个步骤：

  1. 主机写入 binlog：所有对主数据库的更改都会被写入 binlog 文件中。

  2. 从机读取 binlog：从机的 I/O 线程从主机读取 binlog，并将内容写入自己的 Relay log 文件。

  3. 从机应用 binlog：从机的 SQL 线程读取 Relay log，并在本地执行这些操作，以使本地数据库与主机数据库保持同步。

这种复制机制允许从机数据库获取主机数据库的更新，并保持数据的一致性，同时也提供了数据备份和故障恢复的功能。

以下是 MySQL 主从复制机制的详细步骤和工作原理：

1. 主机（Master）的角色

  • 日志记录：主机记录所有数据修改操作到二进制日志（binlog）中。二进制日志包含所有的 SQL 语句（在 statement-based logging 中）或者所有的数据修改操作（在 row-based logging 中）。日志文件按照时间顺序追加新记录。

  • binlog 文件：二进制日志文件由多个日志片段组成，每个日志片段有一个唯一的日志文件名和一个日志位置标记。binlog 文件的内容可以被从机读取并执行。

2. 从机（Slave）的角色

  • 连接主机：从机启动 I/O 线程，通过网络连接到主机，以获取 binlog 数据。

  • 读取 binlog：从机的 I/O 线程从主机读取 binlog 的内容，并将其写入到本地的中继日志（Relay log）中。中继日志是从机本地存储的日志文件，用于记录从主机获取的 binlog 内容。

  • 中继日志：中继日志是一个或多个文件，记录了主机的 binlog 内容。中继日志的每个日志片段都有一个唯一的文件名和位置标记，用于标识日志的顺序。

3. 数据应用过程

  • SQL 线程：从机启动一个 SQL 线程，用于读取中继日志的内容，并将日志中的操作应用到从机的数据库上。

  • 执行操作：SQL 线程读取中继日志中的操作，并将这些操作转换为相应的 SQL 语句，然后在从机的数据库上执行这些操作。这样可以保持从机与主机的数据同步。

4. 复制流程的详细步骤

  1. 主机写入 binlog：

    • 主机上的数据库执行了数据修改操作，这些操作被记录到 binlog 文件中。binlog 文件以追加的方式记录数据修改的历史。

  2. 从机读取 binlog：

    • 从机的 I/O 线程连接到主机，向主机发送一个复制请求，并从主机接收 binlog 文件中的数据。

    • 主机将 binlog 数据通过网络发送到从机的 I/O 线程。

  3. 写入中继日志：

    • 从机的 I/O 线程将接收到的 binlog 数据写入到本地的中继日志中。中继日志保存了从主机接收到的操作记录。

  4. 从机应用数据：

    • 从机的 SQL 线程读取中继日志中的内容，并根据日志中的操作在从机的数据库上执行相应的操作。

    • 执行操作的过程中，如果出现错误，从机会记录错误信息，并根据配置选择是否继续复制或者中断复制。

  5. 日志同步：

    • 从机的 I/O 线程会持续从主机读取新的 binlog 数据并更新中继日志。

    • 从机的 SQL 线程会持续读取中继日志，并应用新的操作，确保从机数据库的最新状态与主机数据库一致。

6. 复制的可靠性与容错

  • 数据一致性：为了保证主从数据的一致性，可以配置复制的事务处理模式，例如，设置 sync_binlog 参数确保 binlog 的写入和磁盘同步。

  • 复制延迟：主从复制可能会存在一定的延迟，具体取决于网络速度、系统负载等因素。

  • 错误处理：从机在执行操作过程中可能会遇到错误。MySQL 提供了一些配置选项来处理错误，例如 relay_log_purge 用于清理旧的中继日志，slave_skip_errors 用于跳过某些错误等。

通过这些步骤，MySQL 实现了主从数据库的同步和数据备份，帮助提高系统的可用性和数据可靠性。

细说Realy log

中继日志（Relay log）是 MySQL 主从复制架构中的关键组件，它的作用是缓存主机（Master）发送给从机（Slave）的二进制日志（binlog）数据。下面是中继日志的详细介绍：

1. 中继日志的基本概念

  • 定义：中继日志是从机本地存储的日志文件，用于记录从主机获取的 binlog 数据。这些日志记录了主机上的所有数据修改操作，用于在从机上重放这些操作以保持数据同步。

  • 结构：中继日志由多个日志文件组成，每个文件都有唯一的文件名和位置标记。中继日志文件的内容是从主机的 binlog 中获取的操作记录的副本。

2. 中继日志的生成和存储

  • 生成：当从机的 I/O 线程从主机读取 binlog 数据时，这些数据被写入到中继日志中。中继日志是从机的本地文件系统上的文件，用于存储从主机接收的操作记录。

  • 存储位置：中继日志文件通常存储在从机的文件系统中的一个指定目录下。可以通过配置参数来设置中继日志的存储位置。

  • 文件管理：中继日志文件是按序号命名的，例如 mysql-relay-bin.000001、mysql-relay-bin.000002 等。新的中继日志文件会在旧文件达到预设的大小限制或者达到时间间隔后自动创建。

3. 中继日志的工作流程

  1. 从主机接收数据：

    • 从机的 I/O 线程连接到主机，向主机发送复制请求，并从主机获取 binlog 数据。

    • 主机将 binlog 数据通过网络传输到从机的 I/O 线程。

  2. 写入中继日志：

    • 从机的 I/O 线程将接收到的 binlog 数据写入本地的中继日志文件中。写入过程中，数据会按照 binlog 的顺序追加到中继日志文件中。

  3. SQL 线程读取和应用：

    • 从机的 SQL 线程定期检查中继日志文件，并从中读取数据。

    • SQL 线程将中继日志中的操作记录转换为相应的 SQL 语句，然后在从机的数据库上执行这些操作，以保持数据同步。

  4. 日志轮换：

    • 中继日志文件会根据配置的限制（如文件大小、时间间隔）进行轮换。当当前中继日志文件达到限制时，会创建一个新的日志文件。

    • 旧的中继日志文件会被标记为已经处理，SQL 线程会继续处理新的日志文件。

4. 中继日志的管理

  • 日志清理：

    • 在从机上，中继日志文件的管理包括清理过时的日志文件。可以通过配置选项 relay_log_purge 来控制是否自动清理旧的中继日志文件。

  • 错误处理：

    • 在从机应用中继日志中的操作时，如果遇到错误（如 SQL 执行错误、数据完整性问题），可以通过配置选项 slave_skip_errors 跳过特定类型的错误，或者停止复制进程并进行人工干预。

  • 监控：

    • 可以使用 MySQL 的状态变量（如 SHOW SLAVE STATUS）来监控中继日志的状态，包括当前使用的日志文件、复制进度、I/O 和 SQL 线程的状态等。

5. 中继日志的优化

  • 日志大小：可以根据系统的负载和网络情况调整中继日志文件的大小，以优化性能和存储效率。

  • 并发处理：在高负载的环境中，可以通过优化 SQL 线程的处理方式，提高中继日志的处理速度，减少复制延迟。

中继日志在 MySQL 主从复制中起着至关重要的作用，它确保了主机和从机之间的数据同步，并提供了可靠的数据备份机制。通过合理的配置和管理，可以有效地维持主从复制的高效运行。

biglog 日志的三种格式

Statement：每一条会修改数据的sql都会记录在binlog中

Row: 仅保存哪条记录被修改

Mixed: 以上两种的混合使用，一般的语句修改用statement，全表更新使用Row，但是无法使用@@host name。

MySQL 中二进制日志（binlog）的三种主要格式。下面是详细的介绍：

1. Statement-Based Logging (SBL)

  • 定义：在 Statement-Based Logging 模式下，每一条修改数据的 SQL 语句都会被记录到 binlog 中。换句话说，binlog 中包含了执行的 SQL 语句。

  • 优点：

    • 简洁：记录的是 SQL 语句本身，相对较小，减少了 binlog 的存储空间。

    • 易于理解：直接记录 SQL 语句，使得日志的内容容易理解和调试。

  • 缺点：

    • 不可重复性：由于 SQL 语句的执行可能依赖于特定的环境（如数据的当前状态），如果从机的环境与主机不完全相同，可能导致复制不一致。

    • 复杂语句问题：某些 SQL 语句（特别是涉及复杂的函数、存储过程等）可能在从机上执行时与主机上的结果不完全一致。

2. Row-Based Logging (RBL)

  • 定义：在 Row-Based Logging 模式下，binlog 只记录哪些数据行被修改了，记录的是行级别的操作（如插入、更新、删除的具体记录）。

  • 优点：

    • 一致性：由于记录了具体的数据行，确保了在主从复制过程中数据的一致性。无论数据的当前状态如何，都会按照主机的操作在从机上执行。

    • 适用性广：适用于任何类型的 SQL 操作，不受数据状态变化的影响。

  • 缺点：

    • 存储空间：由于记录的是行级别的数据，binlog 文件可能比 Statement-Based Logging 模式下的文件要大。

    • 日志文件的复杂性：日志文件内容可能不如 SQL 语句直观，理解和调试可能比较困难。

3. Mixed-Based Logging (MBL)

  • 定义：Mixed-Based Logging 模式是 Statement-Based Logging 和 Row-Based Logging 的混合使用模式。MySQL 会根据特定的情况选择使用 Statement 模式或 Row 模式来记录 binlog。

  • 使用场景：

    • Statement 模式：通常用于普通的 SQL 语句，如简单的 SELECT、INSERT、UPDATE 等。

    • Row 模式：用于复杂的情况，如表的全表更新、大规模的数据更改，或使用了特定的存储引擎功能（如事务、触发器）时。

  • 优点：

    • 平衡：结合了两种模式的优点，能够在需要时保证一致性，同时减少存储空间的使用。

    • 灵活性：根据操作的不同选择合适的日志格式，提高了复制的灵活性和性能。

  • 缺点：

    • 配置复杂性：需要 MySQL 进行智能选择，这可能会增加配置和调试的复杂性。

    • 限制：在 Mixed 模式下，某些功能（如使用 @@hostname）可能会受限，因为日志格式的不一致可能影响到某些操作。

选择和配置

  • 选择日志格式：可以通过设置 binlog_format 参数来选择日志格式：

    • binlog_format=STATEMENT：使用 Statement-Based Logging。

    • binlog_format=ROW：使用 Row-Based Logging。

    • binlog_format=MIXED：使用 Mixed-Based Logging。

  • 配置：在生产环境中，通常会选择适合业务需求的日志格式。例如，Row-Based Logging 可能更适用于需要严格数据一致性的场景，而 Statement-Based Logging 可能在存储空间和性能方面更具优势。

通过理解和选择适当的 binlog 格式，可以优化 MySQL 的主从复制性能，并确保数据的一致性和可靠性。

MySQL技术中主从复制主要解决 数据丢失 问题。

MySQL技术中每一条会修改数据的SQL语句都会记录在binlog日志中的是 Statement 格式。

Mycat高级特性_读写分离概述

什么是读写分离

读写分离，基本的原理是让主数据库处理事务性增、改、删操作，而从数据库处理查询操作。

为什么使用读写分离

从集中到分布，最基本的一个需求不是数据存储的瓶颈，而是在于计算的瓶颈，即 SQL 查询的瓶颈，我们知道，正常情况下，Insert

SQL 就是几十个毫秒的时间内写入完成，而系 统中的大多数 Select SQL 则要几秒到几分钟才能有结果，很多复杂的 SQL，其消耗服务

器 CPU 的能力超强，不亚于死循环的威力。

读写分离方案

MyCat的读写分离是建立在MySQL主从复制基础之上实现的，所以必须先搭建MySQL的主从复制。数据库读写分离对于⼤型系统或者

访问量很⾼的互联网应用来说，是必不可少的⼀个重要功能。

Mycat实现的读写分离和自动切换机制，需要MySQL的主从复制机制配合

Mysql 主从复制的常用拓扑结构

一主一从

最基础的复制结构，用来分担之前单台数据库服务器的压力，可以进行读写分离。

一主多从

一台 Slave 承受不住读请求压力时，可以添加多台，进行负载均衡，分散读压力。

双主复制

双主结构就是用来解决这个问题的，互相将对方作为自己的Master，自己作为对方的 Slave 来进行复制，但对外来讲，还是一个主和一个从。

级联复制

级联结构就是通过减少直接从属于 Master 的 Slave 数量，减轻Master 的压力，分散复制请求，从而提高整体的复制效率。

双主级联

Mysql 的复制结构有很多种方式，复制的最大问题是数据延时，选择复制结构时需要根据自己的具体情况，并评估好目标结构的延时对系统的影响。

MySQL 的级联复制（Cascading Replication）是一种复制拓扑结构，其中从数据库（Slave）本身也可以作为主数据库（Master）的从数据库。级联复制允许创建更复杂的复制架构，支持多级的数据复制。下面是关于 MySQL 级联复制的详细介绍：

1. 级联复制的基本概念

  • 级联复制：在这种复制模式下，除了主数据库和直接的从数据库之外，直接从数据库还可以作为其他从数据库的主数据库。换句话说，从数据库（子从库）可以再有从数据库（孙从库）。

  • 拓扑结构：这种结构可以形成一个层次化的复制拓扑，通常包含以下几个层级：

    • 主数据库（Master）：处理所有的写操作。

    • 直接从数据库（Direct Slave）：从主数据库获取数据，并将其复制到下一级的从数据库。

    • 级联从数据库（Cascading Slave）：从直接从数据库获取数据。

2. 级联复制的工作原理

  1. 数据写入：主数据库接收到数据修改操作（INSERT、UPDATE、DELETE），并将这些操作记录到其二进制日志（binlog）中。

  2. 复制到直接从数据库：

    • 直接从数据库通过 I/O 线程连接到主数据库，读取主数据库的 binlog。

    • 将主数据库的 binlog 写入到自身的中继日志（Relay log）中。

    • SQL 线程从中继日志中读取操作，并在从数据库上执行这些操作。

  3. 复制到级联从数据库：

    • 级联从数据库通过 I/O 线程连接到直接从数据库，读取直接从数据库的 binlog（从直接从数据库的中继日志）。

    • 将直接从数据库的 binlog 写入到自身的中继日志中。

    • SQL 线程从中继日志中读取操作，并在级联从数据库上执行这些操作。

3. 级联复制的优点

  • 减少主数据库的负载：通过将复制负载分散到多个级联从数据库上，可以减轻主数据库的负担。这有助于提高主数据库的性能和稳定性。

  • 灵活的复制拓扑：级联复制支持更灵活的复制拓扑结构，可以在不同的数据中心或地理位置之间进行数据同步和分发。

  • 简化配置：通过级联复制，可以减少直接从数据库的数量，简化配置和管理。例如，多个从数据库可以通过级联复制的方式连接到一个直接从数据库，从而减少直接从数据库与主数据库之间的连接数。

4. 级联复制的缺点

  • 复制延迟：每一级复制都会引入一定的延迟。级联从数据库可能会面临比直接从数据库更大的延迟，因为数据需要经过多级复制才能到达最终的级联从数据库。

  • 复杂性：级联复制增加了复制拓扑的复杂性，管理和故障排除可能变得更加困难。需要注意级联复制中的故障检测和自动切换机制。

  • 数据一致性：由于级联复制的层次结构，数据一致性可能会受到影响，尤其是在复制延迟较大的情况下。需要确保级联从数据库的数据足够新，以避免读取到过时的数据。

5. 配置级联复制

配置级联复制的步骤与普通的主从复制类似，但需要特别注意以下几个方面：

  • 配置直接从数据库：

    • 设置直接从数据库连接到主数据库，读取 binlog，并将其写入中继日志。

  • 配置级联从数据库：

    • 设置级联从数据库连接到直接从数据库，读取直接从数据库的 binlog，并将其写入自身的中继日志。

  • 确保同步：

    • 确保主数据库、直接从数据库和级联从数据库的同步配置正确，以保证数据一致性和复制正常工作。

6. 监控和维护

  • 监控复制状态：使用 SHOW SLAVE STATUS 命令监控每个级联从数据库的复制状态，检查是否有复制延迟、错误或其他问题。

  • 故障处理：设计和实现故障处理策略，确保在主数据库或直接从数据库发生故障时能够迅速采取措施，保证数据的高可用性和业务的连续性。

通过级联复制，可以构建复杂的多级复制架构，以满足不同的业务需求和数据分发要求。然而，需要在设计和实施过程中充分考虑延迟、复杂性和一致性问题。

Mycat读写分离技术基于MySQL主从复制技术实现

Mycat高级特性_搭建读写分离

修改配置文件schema.xml

<schema name="TESTDB" checkSQLschema="false"dataNode="db_node" sqlMaxLimit="100">
</schema>

schema：逻辑库 name ：逻辑库名称

sqlMaxLimit：一次取多少条数据

table：逻辑表

dataNode：数据节点 对应 datanode标签

rule：分片规则 对应 rule.xml

primaryKey: 分片主键 可缓存

分片配置

<dataNode name="db_node" dataHost="db_host" database="db_test" />

name：分片名字

dataHost：分片主机

database：分片数据库

配置读写分离

<dataHost name="host1" maxCon="1000"   minCon="10" balance="2" writeType="0" dbType="mysql"  dbDriver="native" switchType="1"  slaveThreshold="100">
    <writeHost host="" url="" user=""   password=""></writeHost>
</dataHost>

参数：

dataHost：数据主机（节点主机）

dbType：数据库驱动native:MySQL JDBC: oracle SQLServer

switchType： 是否主动读 1

Balance参数设置：

1 balance=“0”, 所有读操作都发送到当前可⽤的writeHost上。

2 balance=“1”，所有读操作都随机的发送到readHost。

3 balance=“2”，所有读操作都随机的在writeHost、readhost上分发

WriteType参数设置：

1 writeType=“0”, 所有写操作都发送到可⽤的writeHost上。

2 writeType=“1”，所有写操作都随机的发送到readHost。

3 writeType=“2”，所有写操作都随机的在writeHost、readhost分上发。

witchType参数设置：

1 switchType="1", 主从自动切换

2 switchType="2"，从机延时超过slaveThreshold值时切换为主读

Mycat高级特性_MySQL双主双从原理

一主一从

是最基础的复制结构，用来分担之前单台数据库服务器的压力，可以进行读写分离。

一主多从

问题：

一台 Slave 承受不住读请求压力时，可以添加多台，进行负载均衡，分散读压力。

如何解决

介绍：

互相将对方作为自己的 Master，自己作为对方的 Slave 来进行复制，但对外来讲，还是一个主和一个从。

MySQL一主一从架构会出现性能性问题

.MySQL双主双从架构解决服务性能问题。

Mycat高级特性_搭建双主双从

环境准备

 

编号

角色

IP地址

端口

机器名

1

Master1

192.168.66.101

3350

node-1

2

Slave1

192.168.66.101

3360

node-2

3

Master2

192.168.66.101

3370

node-3

4

Slave2

192.168.66.101

3380

node-4

创建docker容器

#启动第一台
docker run -d  -p 3350:3306 -e
MYSQL_ROOT_PASSWORD=123456 --name=master1
mysql:5.7 #启动第二台
docker run -d  -p 3360:3306 -e
MYSQL_ROOT_PASSWORD=123456 --name=slave1
mysql:5.7 #启动第三台
docker run -d  -p 3370:3306 -e
MYSQL_ROOT_PASSWORD=123456 --name=master2 mysql:5.7
#启动第四台
docker run -d  -p 3380:3306 -e
MYSQL_ROOT_PASSWORD=123456  --name=slave2
mysql:5.7

修改容器内MySQL配置文件

1、修改master1配置文件

[mysqld]
#主服务器唯一ID server-id=1
#启用二进制日志
log-bin=mysql-bin
# 设置不要复制的数据库(可设置多个) binlog-ignore-db=mysql
binlog-ignore-db=information_schema
9
#设置logbin格式
binlog_format=STATEMENT
# 在作为从数据库的时候，有写入操作也要更新二进制日志 文件
13  log-slave-updates
14 #指自增字段的起始值，其默认值是1，取值范围是1 .. 65535
15 auto-increment-increment=2
16 # 指字段一次递增多少，他的取值范围是1 .. 65535
17 auto-increment-offset=1

2、修改master2配置文件

 [mysqld]
#主服务器唯一ID
server-id=3 #启用二进制日志 log-bin=mysql-bin
# 设置不要复制的数据库(可设置多个) binlog-ignore-db=mysql
binlog-ignore-db=information_schema #设置需要复制的数据库
binlog-do-db=需要复制的主数据库名字 #设置logbin格式
binlog_format=STATEMENT
# 在作为从数据库的时候，有写入操作也要更新二进制日志 文件
log-slave-updates
#指自增字段的起始值，其默认值是1，取值范围是1 .. 65535
auto-increment-increment=2
#指字段一次递增多少，他的取值范围是1 .. 65535 auto-increment-offset=2

3、修改slave1配置文件

[mysqld]
#从服务器唯一ID server-id=2
#启用中继日志
relay-log=mysql-relay

4、修改slave2配置文件

[mysqld]
#从服务器唯一ID
server-id=4 #启用中继日志 relay-log=mysql-relay

双主双从重启服务

1  systemctl restart mysql

配置数据库

1、分别在两个主库中执行创建从库连接账号命令

GRANT replication SLAVE ON *.* TO 'slave' @'%' IDENTIFIED BY '123456';

2、查看两个主库的master状态

 show master status;

两个从库连接到主库

change master to
master_host='192.168.66.101', master_user='slave',
master_port=3350,
master_password='123456',
master_log_file='mysql-bin.000001', master_log_pos=438;

参数：

  master_host：这里的ip就是mysql所在服务器对应的ip  

  master_user ：就是在第一步配置的账号

  master_port： mysql的端口

  master_password：配置的密码   

  master_log_file：file参数

  master_log_pos： Position参数

两个从库启动复制功能

 start slave;

查看连接状态

show slave status \G;

两个主库再互相成为对方的从库

# 在master1上执行
CHANGE MASTER TO master_host = '192.168.66.101',
master_user = 'slave',
master_password = '123456', master_port = 3370,
master_log_file = 'mysql-bin.000001', master_log_pos = 154;
# 在master2上执行
10 CHANGE MASTER TO master_host = '192.168.66.101',
11 master_user = 'slave',
12 master_password = '123456',
13 master_port = 3350,
14 master_log_file = 'mysql-bin.000001',
15 master_log_pos = 154;

两个主库启动复制功能

start slave;

查看连接状态

show slave status \G;

双主双从配置MyCat

vim schema.xml

<dataNode name="db_node" dataHost="db_host" database="test" />
<dataHost name="db_host" maxCon="1000" minCon="10" balance="1"
writeType="0" dbType="mysql"
dbDriver="native" switchType="1" slaveThreshold="100" >
<heartbeat>select user()</heartbeat>
<!-- can have multi write hosts --> <writeHost host="hostM1"
url="192.168.140.128:3306" user="root" password="123456">
<!-- can have multi read hosts -->
<readHost host="hostS1"
url="192.168.140.127:3306" user="root"
11  password="123456" /> 12   </writeHost>
13   <writeHost host="hostM2"
url="192.168.140.126:3306" user="root"
14   password="123456">
15   <!-- can have multi read hosts --> 16   <readHost host="hostS2"
url="192.168.140.125:3306" user="root"
17  password="123456" />
18   </writeHost> 19   </dataHost>  20

writeType="0"：所有写操作发送到配置的第一个 writeHost，第一个挂了切到还生存的第二

个riteHost，重新启动后已切换后的为准，切换记录在配置文件中:dnindex.properties.

writeType="1"：所有写操作都随机的发送到配置的 writeHost，1.5 以后废弃不推荐。

switchType="-1" ：表示不自动切换 mysql 实例

switchType="1" ：默认值，自动切换