MySQL主从、主主复制及高可用性要点

合集下载

MySQL中的高可用解决方案

MySQL中的高可用解决方案

MySQL中的高可用解决方案MySQL是一种常用的关系型数据库管理系统,被广泛用于各种应用场景。

对于很多企业和组织来说,保证MySQL数据库的可用性和可靠性是非常重要的,因为数据库宕机或者数据丢失可能会导致巨大的经济损失和业务中断。

因此,开发高可用解决方案成为MySQL数据库管理者们必须面对的挑战。

一、MySQL复制MySQL复制是MySQL中最常用的高可用解决方案之一。

通过使用MySQL的复制功能,可以将一个主数据库的数据实时复制到一个或多个备份数据库。

当主数据库出现故障时,备份数据库可以顶替其角色,从而实现无缝切换。

MySQL复制是基于日志的机制,主数据库将产生的数据更改事件写入二进制日志(Binary Log),备份数据库则通过读取主数据库的二进制日志来实时复制数据。

主数据库将所有更改记录下来,备份数据库则按照相同的顺序应用这些更改,从而实现数据的同步。

虽然MySQL复制是一种简单且有效的高可用解决方案,但它也存在一些局限性。

首先,MySQL复制是异步的,主数据库和备份数据库之间有一定的延迟,可能会导致数据的不一致。

其次,MySQL复制只能实现单主节点的高可用,即只有一个主数据库,其他都是备份数据库。

这对于一些高并发的应用来说,可能无法满足需求。

二、MySQL集群为了解决MySQL复制的限制,MySQL提供了集群(Cluster)解决方案。

MySQL集群是一种基于共享存储器(Shared Storage)的高可用解决方案。

在MySQL集群中,多个MySQL节点共享相同的数据存储,数据的一致性由底层共享存储器保证。

MySQL集群采用了多个MySQL节点协同工作的方式,每个节点都可以处理客户端请求。

当其中一个节点发生故障时,其他节点可以自动接管服务,保证了系统的连续性。

同时,MySQL集群也提供了负载均衡的功能,可以将请求分发到不同的节点上,从而提高了系统的性能。

然而,MySQL集群也有一些限制。

mysql数据同步原理

mysql数据同步原理

mysql数据同步原理MySQL数据同步原理是指将一个MySQL数据库的数据同步到另一个MySQL 数据库的过程。

以下是MySQL数据同步的基本原理:1. 主从复制:MySQL数据同步最常用的方式是通过主从复制。

在主从复制中,一个MySQL实例(称为主节点)充当数据的源,而另一个MySQL实例(称为从节点)充当数据的副本。

主节点将更新的数据写入二进制日志(binary log),然后从节点通过读取二进制日志的内容来复制主节点的数据。

2. 二进制日志(binary log):二进制日志是记录了主节点上所有修改操作的日志文件,包括插入、更新和删除操作。

从节点通过读取主节点的二进制日志来获取更新的数据,并应用到自己的数据库中。

3. 主从同步过程:主节点在每次提交事务时将更新的数据写入二进制日志,并通知从节点进行同步。

从节点根据主节点发送的二进制日志的位置信息,从相应的位置开始读取二进制日志内容,并将读取的日志内容应用到自己的数据库中,以实现数据的同步。

4. 主节点变更:如果主节点发生故障或需要升级,需要将一个从节点提升为新的主节点。

在这种情况下,需要使用CHANGE MASTER TO 语句将其他从节点切换到新的主节点,并重新进行主从同步。

主节点变更时需要注意的是主从数据的一致性和可用性。

5. 高可用性:为了保证数据同步的高可用性,可以使用主从复制的集群架构,如主主复制或主从链复制,可以实现数据的多点复制和故障转移。

总结起来,MySQL数据同步的基本原理是通过主从复制,主节点将更新的数据写入二进制日志并通知从节点进行同步,从节点根据主节点发送的二进制日志的位置信息读取日志内容并应用到自己的数据库中,从而实现数据的同步。

多图文详细介绍mysql各个集群方案

多图文详细介绍mysql各个集群方案

多图文详细介绍mysql各个集群方案MySQL是一个开源的关系型数据库管理系统,已经成为了业界最流行的数据库之一、由于单机MySQL数据库的性能有限,为了提高数据库的可用性、扩展性和性能,业界提出了各种MySQL集群方案,本文将详细介绍几种常见的MySQL集群方案。

1.MySQL主从复制集群:MySQL主从复制是一种简单而常用的集群方案。

该方案通过一个主数据库和多个从数据库实现数据的异步复制,主数据库负责写入操作,从数据库负责读取操作。

主从复制具有以下特点:-主数据库可以提供写入的高性能,从数据库可以提供读取的高性能。

-从数据库可以用于灾备,一旦主数据库出现故障,可以快速切换到从数据库继续提供服务。

-主从复制的实现较为简单,不需要引入复杂的集群管理软件。

-主从复制的缺点是从数据库的数据有一定的延迟。

2.MySQL双主集群:MySQL双主集群是一种更进一步的集群方案,通过在多个数据库之间实现双向复制,实现了数据库的读写分离。

双主集群具有以下特点:-双主结构可以提供更高的可用性,一旦一个数据库出现故障,可以快速切换到另一个数据库继续提供服务。

-双主结构可以提供更高的性能,读写操作可以同时在两个数据库上进行。

-双主集群的缺点是配置和管理比较复杂,需要保证数据的一致性和冲突解决。

3.MySQL分片集群:MySQL分片集群通过将数据分散到多个数据库节点上实现横向扩展,以应对海量数据的处理需求。

分片集群具有以下特点:-分片集群可以提供无限的水平扩展性,可以随着数据的增长增加更多的节点。

-分片集群可以提供更好的性能,可以将负载均衡到多个节点上。

-分片集群的缺点是管理和维护成本较高,需要处理数据的分片和路由问题。

4.MySQL主备集群:MySQL主备集群通过在多个数据库节点之间实现实时数据同步,实现了高可用性和故障切换。

主备集群具有以下特点:-主备结构可以提供高可用性,一旦主节点出现故障,可以自动切换到备用节点继续提供服务。

MYSQL高可用方案大全

MYSQL高可用方案大全

MYSQL高可用方案大全MySQL是一个开源的关系型数据库管理系统,广泛应用于各种Web应用程序中。

为了确保业务的连续性和高可用性,需要采取一些措施来预防和解决数据库故障。

下面是一些MySQL高可用方案的介绍。

1. 数据库复制(Replication)数据库复制是MySQL提供的一种基本的高可用方案。

它使用了主从模式,将主数据库的更新操作异步地复制到一台或多台从数据库中。

主数据库负责处理写操作,而从数据库负责读操作。

当主数据库发生故障时,从数据库可以接管业务并提供读写服务。

2. 数据库镜像(Mirroring)数据库镜像是一种同步复制的方式,可以确保数据的完整性和一致性。

它通常使用两台或多台服务器,在主库上进行写操作,然后将写操作同步到所有从库上。

这样,当主库发生故障时,可以快速切换到从库并继续提供服务。

3. 数据库分片(Sharding)数据库分片是一种水平切分数据库的方式,可以将大型数据库分成多个较小的部分,分布在不同的服务器上。

每个分片都有自己的主从数据库,可以独立地处理读写请求。

这种方案可以提高数据库的可用性和性能。

4. 数据库集群(Cluster)数据库集群是一种多节点共享存储的方式,可以提供高可用性和高性能。

集群中的每个节点都是一个完整的数据库服务器,它们共享存储,可以同时处理读写请求。

如果一个节点发生故障,其他节点可以接管工作并继续提供服务。

5. 数据库备份与恢复(Backup and Recovery)数据库备份是一种常见的高可用方案,可以在数据库发生故障时恢复数据。

通过定期备份数据库,可以保留历史数据,并在需要时进行恢复。

备份可以分为物理备份和逻辑备份两种方式,具体选择哪种方式取决于业务需求和复杂度。

6. 数据库热备份(Hot Backup)数据库热备份是一种可以在数据库运行时进行备份的方式。

不需要停止数据库服务,可以实时备份数据库的数据和日志。

这样可以减少备份对业务的影响,并提高备份的可用性。

mha方案原理

mha方案原理

mha方案原理MHA(Master High Availability),也称为MySQL高可用性方案,是一种用于提供MySQL数据库高可用性和容错能力的解决方案。

MHA方案通过实现主从复制和自动故障切换等机制,确保在主服务器故障时能够快速切换到备用服务器,从而保证数据库的持续可用性和数据完整性。

MHA方案的原理基于以下几个核心组件和机制:1. 主从复制(Master-Slave Replication):在MHA方案中,主服务器负责处理写操作,并将写操作的日志同步到备用服务器上。

主服务器和备用服务器之间通过二进制日志(Binary Log)进行数据同步,实现主从复制。

备用服务器会不断地从主服务器上获取二进制日志并应用到自身的数据库中,从而保持与主服务器的数据一致性。

2. 自动故障切换(Automatic Failover):MHA方案能够自动检测主服务器的健康状态,并在主服务器发生故障时自动将备用服务器切换为新的主服务器,以保证数据库的持续可用性。

MHA利用监控工具对主服务器进行实时监测,一旦检测到主服务器无法正常工作,MHA会触发自动故障切换机制,选择一个健康的备用服务器作为新的主服务器,并将其他备用服务器配置为新的从服务器,以确保数据的一致性。

3. 心跳检测(Heartbeat):MHA方案通过心跳检测机制来监测主服务器和备用服务器的状态。

主服务器和备用服务器之间会周期性地交换心跳消息,以确认彼此的正常运行。

一旦MHA检测到主服务器的心跳停止,即认为主服务器发生了故障,并触发自动故障切换。

4. VIP漂移(Virtual IP Floating):MHA方案通过VIP漂移机制来实现主从切换时的快速恢复。

在正常情况下,主服务器的虚拟IP(VIP)会绑定到主服务器上,而备用服务器没有VIP,只有真实IP。

一旦主服务器发生故障,MHA会将VIP快速漂移到备用服务器上,使其成为新的主服务器。

这样一来,对外提供服务的IP地址仍然保持不变,客户端无需修改配置即可继续访问数据库。

MySQL数据库高可用与负载均衡解决方案

MySQL数据库高可用与负载均衡解决方案

MySQL数据库高可用与负载均衡解决方案MySQL数据库是一种常用的关系型数据库管理系统,在大型应用中往往需要保证数据库的高可用性和负载均衡。

为了满足这一需求,我们可以采取一系列解决方案。

一、MySQL数据库的高可用解决方案1. 主从复制(Master-Slave Replication)主从复制是MySQL中最常见的高可用解决方案之一。

在主从架构中,一个主数据库(Master)处理写入操作,并将这些操作记录在二进制日志中。

而一个或多个从数据库(Slave)则通过读取主数据库的二进制日志,并将这些操作应用于自身的数据库,从而实现数据的同步。

2. 主主复制(Master-Master Replication)主主复制是一种更加高级的复制解决方案。

在主主架构中,每个数据库既是主数据库又是从数据库。

两个数据库可以同时进行读写操作,并通过异步方式将这些操作同步到对方的数据库中。

这样,即使其中一个数据库发生故障,另一个数据库仍然可以正常提供服务。

3. 数据库集群(Cluster)数据库集群是一种将多个数据库服务器组合在一起工作的解决方案。

在集群中,各个数据库服务器负责不同的数据分片,从而提高数据库的整体性能和可靠性。

当有服务器故障时,集群可以自动将故障节点的数据迁移到其他节点上,从而实现高可用性和负载均衡。

二、MySQL数据库的负载均衡解决方案1. 代理层负载均衡通过在应用程序与数据库之间增加一个代理层,可以实现负载均衡和故障转移。

代理层可以根据负载情况将查询请求分发到不同的数据库服务器上,从而实现数据库的负载均衡。

当某个数据库服务器故障时,代理层可以自动将请求路由到其他正常工作的服务器上,从而保证服务的可用性。

2. 数据库分片数据库分片是将大型数据库拆分成多个较小的数据库片段,分布在不同的服务器上进行存储和处理。

每个数据库片段只负责一部分数据,通过分片键将查询请求路由到相应的片段。

这样可以降低单个数据库的负载,提高整体系统的吞吐量和响应速度。

MySQL主从复制的常见问题与解决方案

MySQL主从复制的常见问题与解决方案

MySQL主从复制的常见问题与解决方案MySQL主从复制是一种常见的数据库复制技术,它可以将一个数据库(主库)的变更同步到其他多个数据库(从库),使得数据的读写操作可以同时在多个数据库中进行。

这种技术在分布式系统中广泛应用,能够提高数据库的性能和可用性。

然而,在实际应用中,MySQL主从复制也会遇到一些常见的问题。

本文将重点讨论这些问题并提供解决方案。

一、延迟复制问题MySQL主从复制的一个常见问题是延迟复制。

由于主库和从库之间的网络延迟或从库的负载过重,导致从库上的数据更新与主库有一定的时间差。

这种延迟可能会导致数据不一致问题,严重影响业务的正确性和稳定性。

解决方案:1. 优化网络连接:检查主从库之间的网络连接,并确保网络带宽足够大,延迟尽可能小。

2. 优化从库性能:如果从库的负载过重,可以考虑增加从库的内存和CPU资源,或者升级硬件设备。

3. 使用并行复制:MySQL 5.6及以上版本支持并行复制,在从库开启并行复制模式,可以提高复制的效率和减少延迟。

二、主从数据不一致问题MySQL主从复制过程中,可能会遇到数据不一致的问题,即从库上的数据与主库不一致。

常见的原因包括:网络故障,主库宕机,复制中断等。

这种问题往往需要及时解决,以避免数据丢失和业务异常。

解决方案:1. 检查主从状态:使用MySQL的命令SHOW SLAVE STATUS检查主从状态,确保主从复制处于正常运行状态。

2. 检查复制延迟:通过比较主库和从库的binlog位置,判断是否存在复制延迟。

如果延迟较大,可以考虑重启从库,重新建立主从复制连接。

3. 检查复制中断原因:如果发现复制中断,可以通过查看错误日志或者SHOW SLAVE STATUS输出,找到中断原因并进行相应的处理。

常见的中断原因有:主库宕机、从库空间不足、主库binlog日志满等。

4. 数据修复:如果数据不一致,可以通过手动修复或者重新同步数据来解决。

可以使用工具如pt-table-checksum和pt-table-sync进行数据校验和修复。

MYSQL高可用方案大全

MYSQL高可用方案大全

MYSQL高可用方案大全MySQL是一种关系型数据库管理系统,用于在应用程序中存储和管理数据。

在实际应用中,数据库的高可用性是非常重要的,因为任何数据库故障或停机都可能导致业务中断和数据丢失。

为了保证MySQL数据库的高可用性,可以采用以下各种方案:1. 主从复制(Master-Slave Replication):这是一种常用的MySQL 高可用方案。

主数据库(Master)负责写入操作,而从数据库(Slave)则复制主数据库的数据,并用于读操作。

当主数据库发生故障时,可以将从数据库提升为主数据库,从而实现故障切换。

2. 主主复制(Master-Master Replication):这种方案允许多个数据库实例都可以进行写操作,并将数据同步到其他数据库实例中。

这样可以提高数据库的可用性和处理能力。

当其中一个数据库实例发生故障时,可以将其切换到其他正常工作的数据库实例上。

3. 数据库分片(Database Sharding):这种方案将数据分割成多个片段,分别存储在不同的数据库实例中。

每个数据库实例只负责一部分数据,从而提高读写性能和扩展性。

当其中一个数据库实例故障时,可以将该片段的数据切换到其他正常工作的数据库实例上。

4. 数据库镜像(Database Mirroring):这种方案是将数据库数据实时复制到另一个数据库实例中,从而提供了数据的冗余备份。

当主数据库故障时,可以将镜像数据库切换为主数据库,保证业务的连续性。

5.数据库备份与恢复:定期对数据库进行备份,并将备份数据存储在不同的存储介质上,如磁盘、云存储等。

当数据库发生故障时,可以从备份数据中进行恢复,保证业务的连续性。

6. 数据库集群(Database Clustering):将多个数据库实例组合成一个逻辑集群,提供高可用性、负载均衡和故障恢复功能。

当其中一个数据库实例故障时,可以将客户端请求转发到其他正常工作的数据库实例上,从而保证业务的连续性。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

一:MySQL复制:MySQL复制简介:将master服务器中主数据库的ddl和dml操作通过二进制日志传到slaves服务器上,然后在master服务器上将这些日志文件重新执行,从而使得slave服务器和master服务器上的数据信息保持同步。

Mysql复制的原理:将数据分布到多个系统上去,是通过将Mysql的某一台master主机的数据复制到其它(slave)主机上,并重新执行一遍来实现的;复制过程中一个服务器充当master服务器,而一台或多台其它服务器充当slave服务器。

master服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。

这些日志可以记录发送到slave服务器的更新。

当一个slaves服务器连接master服务器时,它通知master服务器从服务器在日志中读取的最后一次成功更新的位置。

slave服务器接收从那时起发生的任何更新,然后封锁并等待master服务器通知新的更新。

mysql复制的优点:在slave服务器上执行查询操作,降低master服务器的访问压力当master服务器上出现了问题可以切换到slave服务器上,不会造成访问中断等问题在slave服务器上进行备份,以避免备份期间影响master服务器的服务使用及日常访问Mysql自身的复制功能:是构建大型、高性能应用程序的基础。

mysql支持的复制类型:基于语句的复制:在主服务器上执行的SQL语句,在从服务器上执行同样的语句。

MySQL默认采用基于语句的复制,效率比较高。

一旦发现没法精确复制时,会自动选着基于行的复制。

基于行的复制:把改变的内容复制过去,而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持混合类型的复制::默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制。

MySQL复制技术的特点:数据分布(Data distribution )备份(Backups)负载平衡(load balancing)高可用性和容错性High availability and failover复制的工作过程:master将改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件,binary log events);slave将master的binary log events拷贝到它的中继日志(relay log);slave重做中继日志中的事件,将改变反映它自己的数据。

第一步:master记录二进制日志。

在每个事务更新数据完成之前,master在二日志记录这些改变。

MySQL将事务串行的写入二进制日志,即使事务中的语句都是交叉执行的。

在事件写入二进制日志完成后,master通知存储引擎提交事务;第二步:slave将master的binary log拷贝到自己的中继日志。

首先,slave开始一个工作线程——I/O线程。

I/O线程在master上打开一个普通的连接,然后开始binlog dump process。

Binlog dump process从master的二进制日志中读取事件,如果已经跟上master,它会睡眠并等待master产生新的事件。

I/O线程将这些事件写入中继日志;第三步:SQL slave thread(SQL从线程)处理该过程的最后一步。

SQL线程从中继日志读取事件,并重放其中的事件而更新slave的数据,使其与master中的数据一致。

只要该线程与I/O线程保持一致,中继日志通常会位于OS的缓存中,所以中继日志的开销很小。

二:mysql主从、主主复制:实验拓扑:1.在两台服务器上分别安装mysql(源码安装所依赖的包为perl-DBD-MySQL、mysql-server):2.分别启动mysql和mysql2两台服务器,并设置开机启动:3.修改/etc/f配置文件:vi /etc/f添加如下内容:[mysqld]log-bin=MySQL-bin ###启用二进制日志server-id=1 ###数据库ID号,1:表示为Master;master_id范围:1到231之间的正整数值;每个同步服务器都必须设定一个唯一的编号,否则同步无法正常运行。

在服务器mysql2中只需要修改server-id数据库ID号即可:分别重新启动两台服务器的mysqld服务:1、mysql和mysql2服务器相互设置为主从同步:a.在主mysql服务器上的设置:在数据库中建立www账号,并且允许从任何地址上来登录,密码是123.asd:为了使测试成功,所以我这里以清除防火墙为例:b.在主机名为mysql2服务器上的设置:c.在主机名为mysqld服务器上的f配置文件中添加“binlog_do_db=数据库名”配置项(可以添加多个)来指定要同步的数据库:d.验证主、从同步:首先在主数据库上创建新库“tables”,然后在从数据库上查看新建库是否已同步:在主机名为mysql2的服务器中验证新建库是否已经同步:2、mysql和mysql2服务器相互设置为主主同步(在mysql2和msyql上执行相反的操作,使其互为主从):在主机名为msyql2服务器上的设置:在主机名为mysql主机上的设置:在f文件中添加“binlog_do_db=数据库名”配置项(可以添加多个)来指定要同步的数据库。

整体配置完成后需要重启mysqld服务:验证主主同步:会发现在mysql2服务器上的tables库中新建的users表同步到mysql服务器中:如果主MySQL服务器已经存在,只是后期才搭建从MySQL服务器,在置配数据同步前应先将主MySQL服务器的要同步的数据库拷贝到从MySQL服务器上:(如先在主MySQL上备份数据库,再将备份内容在从MySQL服务器上恢复)三、MySQL主/从模式高可性群集:1.在mysql和mysql2两台服务器上分别安装keepalived软件包:安装keepalived软件包与服务控制在编译安装Keepalived之前,必须先安装内核开发包kernel-devel以及openssl-devel、popt-devel等支持库(rhel6.0中默认已经安装):2.编译安装Keepalived:使用指定的linux内核位置对keepalived进行配置,并将安装路径指定为根目录,这样就无需额外创建链接文件,配置完成后,依次执行make、make install进行安装。

3.使用keepalived服务:执行make install操作之后,会自动生成/etc/init.d/keepalived脚本文件,但还需要手动添加为系统服务,这样就可以使用service、chkconfig工具来对keepalived 服务程序进行管理。

4.分别修改mysql和mysql2服务器中的keepalived.conf配置文件:mysql服务器上的配置文件内容如下:vi /etc/keepalived/keepalived.conf:! Configuration File for keepalivedglobal_defs {router_id MySQL-HA}vrrp_instance VI_1 {state BACKUP###BACKUP将根据优先级决定主或从;MASTER指定为主;SLAVE指定为从.若一方为MASTER,另一方为SLAVE,则表示双机热备(即一主一从). interface eth0virtual_router_id 51 ###确保和mysql2相同,同网内不同集群此项必须不同,否则发生冲突priority 100 ###此处mysql2上设置为99(比mysql服务器优先级低)advert_int 1nopreempt ###不抢占,只在priority高的mysql上设置,mysql2上此项注释掉authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {192.168.10.100}}virtual_server 192.168.10.100 3306 {delay_loop 6lb_algo wrrlb_kind DRpersistence_timeout 50protocol TCPreal_server 192.168.10.1 3306 { ###mysql2上此处改为mysql2服务器的ip地址192.168.10.2 weight 1notify_down /etcl/keepalived/bin/mysql.shTCP_CHECK {connect_timeout 3nb_get_retry 3delay_before_retry 3connect_port 3306}}}mysql主机上的keepalived.conf文件的具体配置如下:mysql2主机的keepalived.conf参考上面的描述修改。

可以使用scp命令把mysql主机上配置好的keepalived.conf文件拷贝到mysql2主机,只要做简单修改即可:我这里通过手工修改:mysql和mysql2上都添加此检测脚本,作用是当mysql停止工作时自动关闭本机的keepalived,从而实现将故障机器剔除(因每台机器上keepalived只添加了本机为realserver):当mysqld正常启动起来后,要手动启动keepalived服务。

vi /etc/keepalived /mysql.sh,脚本内容如下:5.如果mysql.sh脚本不能正常执行的话,可以编写一个检测mysqld服务的是否正在运行的脚本,如果mysqld服务停止,则在脚本中停掉keepalived服务,实现故障切换。

并设置一个cron计划任务定期执行检测脚本。

在企业网络内配置cacti 或nagios对mysqld服务进行监控,能在第一时间通知管理员mysqld服务出现异常。

vi /etc/rc.localmodprobe ip_vs ###此模块如果无法自动加载则需手动加载mysql和mysql2启动keepalived守护进程./etc/init.d/keepalived start6.进行测试:在mysql上创建一个测试数据库并在数据库tables库中创建一个www表,此时在mysql2上就会自动同步在mysql上已创建好的库和表;同样在mysql2上对数据库或表做任何修改也会同步到mysql上。

这说明mysql的主从同步实现了:数据库、表都同步,tables库中的内容自动同步:在mysql和mysql2分别执行ipaddrshow dev eth0命令查看mysql和mysql2对VIP(群集虚拟IP)的控制权:整个环境设置到此完成。

相关文档
最新文档