前言
今天汇总一下MySQL高频面试题，希望能帮助你😀
面试题大全
- MySQL集群的作用是什么?
答:MySQL集群的作用是实现MySQL的高可用,通过多台MySQL服务器组成集群,当某一台服务器down机或发生故障时,可以自动切换到其他正常工作的服务器上,保证MySQL服务的连续性。 - MySQL集群的结构由哪些组件组成?
答:MySQL集群由管理节点(Management Node)、数据节点(Data Node)和SQL节点(SQL Node)三个组件组成。
管理节点:管理整个集群,配置和监控数据节点。
数据节点:存储数据,处理SQL查询。
SQL节点:接受应用连接,解析SQL查询,并与数据节点通信。 - MySQL集群有哪几种部署模式?
答:MySQL集群有三种主要的部署模式:- 单一管理节点模式:一个管理节点,多个数据节点和SQL节点。
- 多管理节点模式:多个管理节点,多个数据节点和SQL节点,管理节点之间无主从关系,并行工作。
- 管理节点高可用模式:多个管理节点,其中有一个主管理节点,其他为从管理节点,多个数据节点和SQL节点。主管理节点down机后,从管理节点接管工作。
- MySQL集群的搭建工具有哪些?
答:MySQL集群的搭建工具主要有:- MGM(MySQL Cluster Manager):MySQL官方提供的集群管理工具,基于MySQL Shell开发。
- ndb_mgmd:MySQL自带的管理节点进程。可以手动启动管理节点、数据节点和SQL节点进行集群搭建。
- Docker:可以通过Docker快速搭建MySQL集群。
- Kubernetes:Kubernetes也可以实现MySQL集群的自动化部署。
- 使用MGM工具搭建MySQL集群的步骤是什么?
答:使用MGM工具搭建MySQL集群的主要步骤如下:
安装MGM及其依赖。MGM依赖MySQL Shell、MySQL Server和MySQL Router。
创建集群配置文件,指定集群名称、管理节点、数据节点和SQL节点信息。
初始化集群配置。使用mgm cluster deploy命令初始化集群配置。
启动集群。使用mgm cluster start命令启动集群。
添加SQL节点。使用mgm sql node add命令添加SQL节点进集群。
测试集群连接。使用MySQL客户端连接SQL节点测试集群。
停止集群。使用mgm cluster stop命令停止集群。 - 数据在MySQL集群中是如何存储的?
答:在MySQL集群中,数据是通过数据节点来存储的,每个数据节点都保存数据的一份副本。MySQL集群采用主备复制方式实现数据的高可用,每个数据片(partition)在两个数据节点上保存一份主副本,其中一个为主复制,另一个为从复制。主从复制通过异步复制实现数据的同步。 - MySQL集群的切换过程是怎样的?
答:MySQL集群的切换过程如下:
检测到主数据节点不可用,选举算法选举出从数据节点为新的主数据节点。
新主数据节点切断与旧主数据节点的连接,并完成相关的配置更新。
新主数据节点开始接受 outside-MySQL 客户端连接和处理查询请求。
新主数据节点基于logs重新执行有状态的事务,保证数据的一致性。
客户端连接自动切换到新主数据节点,整个切换过程对客户端透明。 - MySQL集群的扩容过程是怎样的?
答:MySQL集群的扩容过程如下:
添加新数据节点。使用mgm数据节点添加命令添加新数据节点。
重新分片。添加新数据节点后,需要重新分片以平衡各数据节点的数据量。可以使用mgm集群重新分片命令完成重新分片操作。
同步新数据节点数据。新添加的数据节点的数据是空的,需要同步其他数据节点已有的数据。首先同步元数据,即数据库、表结构,然后同步业务数据。
测试并上线新数据节点。同步完成后,测试新数据节点,确认无异常后可以上线使用。
新分片生效。重新分片完成后,新分片的元数据及数据同步完成,新分片正式生效。
9.优化MySQL集群的性能?
答:优化MySQL集群的性能可以从以下几个方面进行:
选择合适的硬件,如高性能CPU、充足的内存、高速缓存和网络等。
选用高性能的磁盘阵列,使用SSD磁盘等。
调整各配置参数,如并发连接数、缓存大小等。
数据库设计优化,如规范的表结构、关键字段索引等。
SQL语句优化,避免全表扫描等低效SQL。
负载均衡,避免单节点过载,从而影响整个集群的性能。
节点个数适当,太多节点会增加通信消耗性能,太少会限制扩展性。
其他,如使用读写分离等。 - MySQL集群的主备切换机制是什么?
答:MySQL集群的主备切换机制是基于数据节点的主备切换来实现的。其主要过程如下:
数据节点的心跳检查机制定期检查主备数据节点的连接状态。
当主数据节点发生故障时,备数据节点在超过一定时间未接收到主数据节点的心跳包后,会认为主数据节点发生故障。
备数据节点然后发起选举,获得选举成功后成为新的主数据节点。
新主数据节点将旧主数据节点标记为故障,视情况切断连接。同时新主数据节点开始接受读写请求。
客户端连接会自动切换至新主数据节点,故障切换对客户端透明。
旧主数据节点恢复后,需要手动进行主备切换,指定其为备数据节点,然后完成数据同步。 - 如何手动进行MySQL集群的数据节点主备切换?
答:手动进行MySQL集群的数据节点主备切换的步骤如下:
使用ndb_mgm管理节点客户端连接管理节点。
检查数据节点状态,确认主备数据节点都是正常状态。
使用SET node_id=主数据节点ID FIRST命令设置当前主数据节点为备数据节点。
使用SET node_id=备数据节点ID FIRST命令设置备数据节点为新的主数据节点。
使用SHOW命令检查数据节点状态,确认主备数据节点已经切换。
等待一段时间,确认备数据节点已完成状态同步,成为新的主数据节点。
客户端重新连接集群测试,确认连接已经切换到新的主数据节点。
可选,设置新的备数据节点防止脑裂,使用SET node_id=旧主数据节点ID BACKUP命令。
确认主备切换成功。新主数据节点提供写服务,旧主数据节点同步新主数据节点并提供备份服务。 - MySQL集群的脑裂问题是什么?如何防止和解决?
答:MySQL集群的脑裂问题是在主备切换时,出现两个数据节点同时认为自己是主节点的情况,导致数据出现不一致的问题。
防止脑裂可以配置数据节点的主节点保护参数,限制主备切换次数,超过主节点保护次数的备数据节点在选举中不会被选举为主节点。
发生脑裂后,可以通过以下步骤解决:
使用ndb_mgm检查集群状态,找到主写数据节点和从写数据节点。
设置其中一个数据节点为备数据节点,使用SET node_id=主数据节点ID BACKUP命令。
设置另一个数据节点为主数据节点,使用SET node_id=从数据节点ID FIRST命令。
等待备数据节点完全同步主数据节点后,在ndb_mgm中使用SHOW查看数据节点同步状态。
同步完成后,在应用端重新连接集群,连接主数据节点,确认写入数据正确。
设置新的备数据节点防止脑裂。使用SET node_id=旧主数据节点ID BACKUP命令。
问题解决。集群继续正常运行。 - 为什么要用共享存储来部署MySQL集群?
答:使用共享存储来部署MySQL集群有以下好处:
简单方便。数据只需要保存一份在共享存储中,各数据节点直接操作共享存储中的数据副本。无需像基于数据复制的集群一样需要在多个数据节点间复制和同步数据。
避免单点故障。共享存储本身也采用集群部署,以避免出现单点故障,从而提高MySQL集群的可靠性。
容易备份。只需要在共享存储层做备份,各数据节点的数据是共享的,无需在各数据节点分别做备份。
易于扩展。通过简单添加数据节点和改造共享存储的配置即可轻易扩展MySQL集群的性能和容量。
节省存储空间。数据只保存一份,无需在每个数据节点都保存一份数据副本,从而节省存储空间。 - MySQL集群共享存储的实现方式有哪些?
答:MySQL集群共享存储的常见实现方式有:
SAN(Storage Area Network)。通过光纤通道或者iSCSI等连接存储设备和服务器,将远程存储设备加入本地存储区域网络,实现存储的共享。
NAS(Network Attached Storage)。通过网络连接存储设备,将存储以文件服务器形式导出,实现不同服务器对存储的访问。
DFS(Distributed File System)。使用分布式文件系统,如GlusterFS、MooseFS等,封装多个存储设备,并导出为一个统一的文件系统使用。
ASM(Automatic Storage Management)。Oracle ASM可以将多个存储设备抽象为一个逻辑存储单元,并提供相关的功能如着陆点、重均衡和镜像等。ASM可以实现MySQL集群的共享存储。
RBS(Raw Block Storage)。将多块存储设备虚拟为一个存储块设备,各个数据节点挂载这个存储块设备使用。
PV(Physical Volume)。使用LVM(Logical Volume Manager)将多块存储设备打成PV,然后组合成VG(Volume Group)和LV(Logical Volume)供各数据节点使用,实现共享存储。
其它。如DRBD、Sheepdog、Ceph RBD等也可以实现MySQL集群的共享存储。 - ASM是如何实现MySQL集群的共享存储的?
答:使用ASM(Automatic Storage Management)实现MySQL集群共享存储的步骤如下:
ASM环境准备。安装ASM和相关依赖,配置ASM disk string, 初始化ASM磁盘。
创建ASM disk group。使用asmcmd工具创建ASM disk group,该disk group将抽象多个物理磁盘为一个逻辑存储单元。
创建ASM volume。在disk group上创建相应的卷,用于MySQL数据存储。使用NORMAL或HIGH冗余级别,Mirrored或Striped等布局类型。
配置MySQL使用ASM。配置MySQL使用ASM存储引擎,指定使用的disk group和volume。
MySQL集群各数据节点挂载相同的ASM volume。各数据节点可以直接访问相同的存储卷,实现共享存储。
MySQL集群启动和使用。启动MySQL集群,创建表时使用的存储引擎为ASM,数据会保存到步骤4中配置的ASM volume上。
ASM管理和监控。使用asmcmd或ASM API监控ASM运行状态,如磁盘故障、恢复和重均衡等,保证存储高可用。
备份恢复。可直接在ASM layer做数据备份与恢复,简单方便。各数据节点数据共享,只做一份备份。 - MySQL Semi-sync复制的作用是什么?
答:MySQL Semi-sync复制的作用是通过半同步复制提高MySQL复制的可靠性。
在异步复制下,主库完成事务提交后直接返回成功,不等待从库接收和应用事务日志。这会导致主库故障时,主库已提交但未同步到从库的事务数据丢失的可能。
Semi-sync复制机制在主库提交事务后,会等待至少一个从库接收到事务日志后再返回成功,从而避免了该数据丢失的可能,提高了数据可靠性。但实际数据持久化还是异步进行的。 - MySQL Semi-sync复制的工作原理是什么?
答:MySQL Semi-sync复制的工作原理如下:
主库提交事务后,首先判断是否开启Semi-sync,如果未开启,正常异步复制。
如果开启Semi-sync,则判断是否至少有一个从库支持Semi-sync,如果不存在,也正常异步复制。
如果存在支持Semi-sync的从库,主库会向其发送事务提交确认请求。
支持Semi-sync的从库接收到请求后,先在relay log中记录事务日志,然后向主库发送确认消息。
主库接收到至少一个从库的确认消息后,才会返回提交成功的状态,完成事务提交。
后续的事务日志异步在各从库间传送、应用。
如果在超时时间内未收到从库确认,主库会强制完成事务提交,以保证主库的响应性。这时 数据可靠性无法保证,属于异步复制。
如果所有从库同时不可用,Semi-sync自动禁用,主库自动切换为异步复制模式。
支持Semi-sync的从库需要开启relay_log_info_repository表来保存对应事务的位点信息。
以上就是MySQL Semi-sync半同步复制的基本工作原理。Semi-sync能很好的兼顾数据可靠性和主库性能。 - 如何配置MySQL Semi-sync复制?
答:配置MySQL Semi-sync复制的步骤如下:
在主库和从库上启用Semi-sync插件。主库安装rpl_semi_sync_master插件,从库安装rpl_semi_sync_slave插件。
在主库上启用Semi-sync复制。设置rpl_semi_sync_master_enabled为ON,并配置超时时间rpl_semi_sync_master_timeout。
在从库上启用Semi-sync复制。设置rpl_semi_sync_slave_enabled为ON。
在从库上创建relay_log_info_repository表。该表用于存放semi-sync的状态信息。
重新启动主从库的复制线程。使Semi-sync配置生效。
在主库上查看Semi-sync状态。show variables like 'rpl_semisync%';
在从库上查看Semi-sync状态。同上。
到此,MySQL Semi-sync半同步复制配置完成。主库在收到至少一个从库确认后提交事务,否则在超时时间过后强制提交。
可通过设置更多从库以提高可靠性,主库接收多个从库确认后才提交事务。设置rpl_semi_sync_master_wait_no_slave为相应数字。
也可通过设置rpl_semi_sync_master_wait_point为AFTER_SYNC或AFTER_COMMIT进一步控制主库提交时机。 - 为什么要使用MySQL读写分离?
答:使用MySQL读写分离的主要好处有:
提高并发量。通过分离读写,可以使用多个从库进行读操作,从而提高MySQL的并发读取能力和系统的吞吐量。
降低主库负载。主库只处理写请求,无需处理读请求,大大减轻主库的负载,从而提高主库的稳定性。
避免主备延迟。从库可以选择与主库的同步方式,如同步复制或半同步复制,避免主备数据延迟过大的问题。
灾备提高。当主库发生故障时,可以快速将一个从库提升为新的主库,使用户可以快速恢复访问。
节省资源。无需在每个从库都部署写实例,只在主库上部署,节省系统资源。 - MySQL读写分离的实现方式有哪些?
答:MySQL读写分离的常见实现方式主要有:
应用端代理实现。在应用层使用代理,根据SQL语句中的指令或者请求类型分发到主库或者从库。简单但是需要应用侧开发。
MySQL Proxy实现。使用MySQL Proxy,可以根据SQL语句和绑定变量智能分发读写请求,实现透明的读写分离。
Middleware实现。使用中间件产品,如Mycat等,对上层应用屏蔽了主从库实现细节,可以灵活实现读写分离和分表分库。
MySQL Router实现。MySQL Router可以根据读写请求的特性智能分发到后端主从库集群,实现透明的读写分离。
存储过程实现。通过在主库上创建存读类型的存储过程,在存储过程内判断语句类型并执行,实现透明的读写分离。
SQL语句监控。通过在主库上使用事件监控SQL语句,在事件触发时判断SQL类型并重定向至从库,实现读写分离。
第三方工具实现。使用第三方提供的读写分离解决方案,如Alibaba的DRDS等。提供透明的读写分离功能。
自定义读取链接的方式。应用在连接数据库时,自行判断使用主库链接还是从库链接,实现简单的读写分离。 - MySQL读写分离下,如何处理主库宕机的情况?
答:MySQL读写分离下,主库宕机的情况可以通过以下方式处理:
自动主备切换。如果部署了主备复制,在主库宕机后可以自动执行主备切换,将一台从库提升为新的主库,实现高可用。这需要配置主备切换的参数和检测机制。
手动主备切换。如果未配置自动切换,在主库宕机后,需要手动执行主备切换,设置一台正常工作的从库为新的主库,其他从库切换复制源至新的主库。
只读模式。如果主库宕机,且暂 time 无法执行主备切换,可以将所有从库设置为只读模式,阻止写操作,保证数据不被修改,等主库恢复后从主库同步最新数据。
应用层降级。在主库不可用的情况下,应用层可以判断主库不可用,并暂时禁止写操作,降级为只读模式,等待主库恢复后切换回主库。
多主切换。如果部署了多主复制,在一台主库宕机后,直接切换至其他正常工作的主库,无需执行主备切换。
其他。部分工具或中间件也提供了主库宕机后的处理方案,可以根据产品手册进行操作。
一般来说,自动主备切换是较为理想的方式,可以最大限度保证业务的连续性。手动切换或只读模式在自动切换不可用时可以作为备选方案。应用层降级也是在类似MySQL集群等情况下常用的方式。 - MySQL可以实现自动主备切换吗?如何实现?
答:MySQL可以实现自动主备切换,主要依靠以下机制实现:
主备心跳检测。通过主备之间的心跳检测机制,即主库定期检测备库的运行状态,如果在指定时间未检测到备库的心跳,则认为备库不可用。同理,备库也定期检测主库。
主从同步监控。备库定期获取主备延迟信息,如果主备延迟超过指定阈值,则认为主库不可用。
外部监控。使用外部监控系统定期监控主备的关键指标,如连接数、查询响应时间等,如果监控指标超出正常范围,则认为相关实例不可用,触发告警。
自动故障判定。根据上述心跳检测、同步监控和外部监控的结果,如果判断主库不可用,则直接将备库提升为新的主库,完成自动主备切换。
重新配置主备关系。将原主库配置为新主库的备库,其他备库也配置新主库为其主库,完成主备关系重配置。
重新提交事务。新主库根据主库的binlog事件重新提交主库已提交但未同步到备库的事务,保证数据的完整性和一致性。
通知Layerswitch。通知上层应用主备已经切换,重新连接数据库。如果使用Proxy等中间件,也需要通知其主备已经变更。 - MySQL InnoDB Cluster是什么?有什么优点?
答:MySQL InnoDB Cluster是MySQL 8.0中引入的native集群解决方案。它具有以下主要优点:
无需要外部集群中间件。InnoDB Cluster使用MySQL自身的组件如MySQL Router、MySQL Shell等实现集群功能,无需依赖外部产品。
简单易用。可以使用MySQL Shell非常简便的创建和管理InnoDB Cluster集群。
高可用。通过多主模式和自动主备切换,实现无单点故障和自动故障转移。
可伸缩。可以在线增加和删除实例,轻松扩展集群的容量和性能。
数据一致性。通过强同步复制和多主写入冲突检测及解决,保证集群中数据强一致。
透明访问。使用MySQL Router,应用可以透明访问集群,无需关心后端具体拓扑结构。
自动重新配置。在主从切换或实例上下线等情况下,集群会自动重新配置主备关系和路由信息等。
REST API管理。提供REST API接口,可以使用各种编程语言管理和监控集群。
安全访问。内置支持基于密码、SSL/TLS和SHA-2认证的安全连接。
其他。还提供在线备份、监控信息收集等功能。
InnoDB Cluster将MySQL的分布式功能推向新的高度,通过其简单易用、高可靠和自动化的特性,可以快速构建MySQL高可用集群架构。 - InnoDB Cluster的工作原理是什么?
答:InnoDB Cluster的工作原理可以概括为以下几点:
组件。主要由MySQL Server实例(主库、从库)、MySQL Router和MySQL Shell组成。
多主模式。默认配置3个主库,并使用强同步复制实现数据一致性,提供高可用性能。
主从复制。除多主实例外,还部署备库实例,与某主库建立主从复制关系。当主库异常时,备库可以快速提升为新的主库。
自动重新配置。在主备切换或实例下线等情况下,InnoDB Cluster会自动重新配置主备关系和MySQL Router的路由信息等。
数据一致性。在多主模式下,通过基于GTID的强同步复制实现数据强一致;在主备切换时,新主库会自动重新提交旧主库已提交但未同步事务,保证数据完整性。
故障检测。InnoDB Cluster通过心跳检测、同步监控和外部监控检测实例故障,触发自动备库提升和重新配置。
MySQL Router。为客户端提供统一入口,并可以根据读写类型智能分发到后端主库或从库,实现读写分离。
自动分片。InnoDB Cluster支持通过HASH或RANGE分片自动分布数据到集群中的实例上。
在线伸缩。可以在线增加主库或从库实例以扩展集群性能,也可下线实例用于维护。
REST API。提供REST API用于管理InnoDB Cluster集群和监控集群状态。 - 如何创建一个InnoDB Cluster集群?
答:创建一个InnoDB Cluster集群可以通过以下步骤实现:
准备至少3台MySQL 8.0及以上版本的服务器,并确保网络互联。
在每台服务器上配置MySQL,设置server_id, binlog等参数,并开启GTID。
在一台服务器上登录MySQL Shell。
初始化AdminAPI。使用MySQL Shell的dba.createCluster()方法初始化AdminAPI,指定第一个主库实例的连接信息。
添加两个主库实例。使用cluster.addInstance()方法添加另外两个主库实例到集群。
添加从库实例。使用cluster.addInstance()方法继续添加一个或多个从库实例到集群。
检查集群状态。使用cluster.status()查看集群运行状态,3主库Status应显示为ONLINE,从库显示为RECOVERING或ONLINE。
部署MySQL Router。在所有实例之外的服务器上部署MySQL Router,使用dbdeployer命令连接集群并生成Router配置。
检查Router配置。Router生成的配置文件位于/var/www/mysqlrouter/mysqlrouter.conf,包含3个主库和从库实例信息。
启动MySQL Router。使用systemctl start mysqlrouter命令启动Router。
使用Router连接集群。通过Router的端口连接集群,可自动连接主库实例,实现读写分离等功能。
在线扩容和维护。可使用cluster.addInstance()继续添加主库或从库,或使用cluster.removeInstance()下线实例用于维护。集群会自动重新配置。
其他管理。可使用MySQL Shell和AdminAPI提供的各种功能管理集群,如设置只读模式、手动主备切换或重新启动等。
这些步骤可以轻松创建一个MySQL InnoDB Cluster集群。利用其强大的管理功能和高可用特性,可以架构出高性能的数据库系统。 - MySQL InnoDB Cluster的常见问题有哪些?
答:MySQL InnoDB Cluster的常见问题主要有:
主库选举失败。由于网络抖动或参数配置问题,导致集群主库选举失败, 没有 PRIMARY 主库被选举出来。可以检查network配置和选举参数设置。
数据不同步。主从复制延迟过大或数据不同步,导致主备切换后数据不完整。应检查网络连接和复制参数设置。
自动重新配置失败。主备切换或新增主库时,自动重新配置过程失败。可手动执行恢复步骤并检查相关日志排查原因。
Router访问失败。Router无法正常访问后端实例。检查Router配置和各实例网络联通性。
nance用户密码过期。InnoDB Cluster使用的内部账户nance用户密码过期导致集群功能异常。需要重置nance用户密码。
实例过多导致性能下降。当实例数量过多时,心跳检测和重新配置过程会影响数据库性能。应评估实例数量并进行调整。
AJD不生效。添加新实例时自动分片功能AJD不生效,新实例没有获得数据分片。检查相关参数设置和数据分布情况。
GTID不同步。GTID不同步导致新增实例获取不到正确的复制位置,无法与集群同步。应手动获取并设置正确的GTID位置使实例正常工作。
设置超时报错。使用AdminAPI设置实例属性时报超时错误。检查网络连接等是否有延迟,或适当增加超时参数时间。
其他。主主冲突、系统权限问题等也会导致InnoDB Cluster异常。应根据报错信息进行相关检查和解决。 - MySQL Group Replication是什么?有什么优点?
答:MySQL Group Replication是MySQL的分布式多主复制解决方案。它具有以下主要优点:
分布式多主模式。支持多达9个主库实例,提供高可用性和高并发度。
数据一致性。通过强同步复制和提交冲突检测机制实现强数据一致性。
高可扩展。可以动态添加新的主库实例,轻松扩展Group Replication集群。
故障自动恢复。在主库实例异常时,集群可以自动进行主库选举并重新配置,快速恢复高可用状态。
安全连接。支持SSL/TLS和SHA-256等安全连接方式,保证数据传输过程安全。
灵活配置。提供多种配置选项,如同步复制方式、自动重新配置选项和提交方式选择等。
多样API。支持MySQL C API、Java API、X Plugin API和HTTP API等访问和管理Group Replication集群。
兼容InnoDB和MyRocks。支持InnoDB和MyRocks两种存储引擎,可根据需求选择。
与PXC兼容。Group Replication实现与PXC高度兼容,可平滑迁移至Group Replication。
其他。还提供在线备份,基于GTID的增量备份,监控信息收集等功能。
Group Replication可以轻松构建MySQL强一致的多主分布式集群,具有很高的可扩展性、高可用性和灵活性,是MySQL企业级高可用方案的理想选择。 - MySQL Group Replication的工作原理是什么?
答:MySQL Group Replication工作原理可以概括为以下几个方面:
组件。主要由多个MySQL Server实例(主库)和Group Replication插件组成。
多主模式。默认最多9个主库实例,通过强同步复制和冲突检测机制实现强一致。
强同步复制。通过多线程复制机制并发同步数据到各实例,并在提交前等待所有实例确认,实现强同步。
冲突检测。使用写冲突检测算法检测不同主库并发写同一行的行为,并进行提交拒绝或自动合并以保证数据一致。
自动恢复。发现主库实例异常后,会自动从正常实例中选举出新的主库,并重新配置集群,快速恢复高可用。
广播协议。使用组播或多播协议在实例间传播日志记录及其他信息,加快信息流通速度。
三阶段提交。在提交事务前使用准备和确认阶段保证所有实例已准备好提交,再统一提交以实现强一致。
GTID集群复制。使用基于GTID的复制方式在各主库实例间复制和同步数据。
隔离机制。提供事务隔离机制,在提交前检测并拒绝读已修改但未提交数据的行为,避免读取脏数据。
增量备份。基于GTID支持在线增量备份,简化备份过程。 - 如何部署MySQL Group Replication集群?
答:部署MySQL Group Replication集群可以通过以下步骤实现:
准备至少3台MySQL Server,版本要求5.7.17或者更高,并确保网络互通。
在每台服务器上配置MySQL,设置server_id, binlog等参数,并开启GTID。
安装Group Replication插件。使用INSTALL PLUGIN语句在每台MySQL Server上安装插件。
配置Group Replication。设置group_replication_group_name,group_replication_start_on_boot等参数。
启动Group Replication。使用START GROUP_REPLICATION命令在一台MySQL上启动,添加第一个主库。
添加其他主库。在其他MySQL Server上同样安装插件、设置参数并使用START GROUP_REPLICATION命令加入集群。
检查集群状态。使用SELECT * FROM performance_schema.replication_group_members;语句查看所有主库状态,都应为ONLINE。
扩容和维护。使用STOP GROUP_REPLICATION命令在线下线主库实现扩容或维护,集群会自动重新配置。
访问集群。可以通过任意主库实现读写,由Group Replication内部实现同步。
其他管理。提供丰富的参数用于管理事务隔离级别、自动重新配置选项、复制方式选择等。
GTID同步。新加入主库获取最新的GTID位置,与集群实现GTID同步。
选举超时。当选举新主库超时,可通过group_replication_force_members手动指定新的主库。
这些步骤可以轻松构建一个MySQL Group Replication集群。通过其强大的功能,可以实现高性能、高可扩展的数据库集群方案。 - MySQL Group Replication的常见问题有哪些?如何解决?
答:MySQL Group Replication的常见问题及解决方法有:
无法选举主库。由于网络或参数问题导致无法自动选举主库。可检查相关参数如group_replication_force_members等进行设置。
数据不同步。主从延迟过大导致数据不同步。应检查网络状况和相关参数调整同步性能。
自动重新配置失败。当有主库下线时,自动重新配置过程失败。应手动指定新的主库并重新启动其他实例。
广播搞问题。由于网络问题导致广播协议异常,集群通信失败。检查网络联通性和相关参数设置。
新加实例同步失败。新实例无法与集群实现正常同步。应检查GTID参数设置和获取正确的GTID同步位置。
事务冲突过多。由于业务写入过于频繁导致事务冲突频发,影响性能。应评估业务写入方式和集群配置。
SET参数不同步。SET参数在各主库上设置不一致,导致功能异常。应在所有主库上设置关键SET参数。
系统权限不足。由于权限问题导致相关目录无法访问,集群运行报错。应检查权限设置并授予相关权限。
其他。SSL连接问题、备份备份失败等其他因素也可导致Group Replication异常。应根据报错信息进行检查和设置。
MySQL 集群高可用面试题