ES集群搭建、分片优化与MySQL数据同步实战解析

1. 为什么说集群、分片、MySQL同步是ES入门的三个坎如果你刚把ElasticSearch的单机版跑起来往里面塞了几万条测试数据用Kibana画了两张图表然后觉得自己已经会了——那我要泼一盆冷水离能上生产还差得远。单机ES就像一个摆在实验室里的玩具发动机能转、能看但你真要拿它去带一整辆车上路第一脚油门它就会给你脸色看。我见过太多人死在这三件事上第一集群。明明多起几个节点就完事结果节点之间互相找不到、脑裂、分片不迁移、集群状态变红——运维噩梦全来了。第二分片。很多人把ES当成一个超大号的MySQL来用建好索引就不管了结果数据量一上来查询从毫秒级掉到秒级还不知道问题出在分片设计上。第三同步MySQL数据。业务库在MySQL里躺着搜索需求一来产品经理说把数据库里的数据都同步到ES里吧你老老实实写代码一把梭——然后全量同步跑了三天三夜内存爆了增量同步又频繁丢数据被DBA追着骂。这篇东西就是围绕这三个坎写的。我会用一套完整的实战过程把它们挨个讲透怎么搭一个三节点的集群、分片和副本到底怎么分配才合理、怎么把MySQL的数据稳定地同步进ES。内容偏操作向但每一步我都会解释为什么这么干因为只给命令不给理由的文章我从来不看我相信你也不愿意看。适合这几类人ES入门一段时间、正在准备上生产的朋友被集群莫名其妙的坑折磨过的运维同学以及被MySQL数据同步ES逼到想转行的后端开发。如果你是纯零基础建议先能把单机ES跑起来再来读不然有些地方你会跟不上。2. 集群的核心机制节点角色、发现与脑裂在动手搭建之前我强烈建议你先花十分钟理解集群的几个底层概念。这一步省不得因为我见过太多人配置写得一模一样结果第一个节点启动就把后面几个节点挤下线了——根因就是没搞懂节点角色。2.1 节点角色谁在干活谁在管事儿ES集群里的每个节点都可以承担不同角色角色是通过配置文件里的node.roles指定的。理解角色的关键是ES不是一个所有节点地位平等的系统它内部有明确的分工。三个核心角色你必须知道master节点负责集群层面的管理操作比如创建删除索引、分配分片、维护集群状态。注意master不参与文档的索引和查询——别指望把master当存储节点用。data节点真正存数据、执行查询和写入的节点。这是集群里最累的角色CPU、内存、磁盘压力都在它身上。coordinating节点只接收请求、路由转发、汇总结果不存数据。小集群用不上但大集群里它很有价值。默认情况下一个节点同时承担所有角色也就是node.roles为空。这对小集群没问题但如果你打算长期跑建议把职责拆开。我在配置三节点集群时通常会让三个节点都设置成可选master和数据节点这样既省机器又能保证高可用。如果你的机器资源足够可以考虑单独加一个 coordinating 节点来承接查询压力。2.2 节点发现为什么三个节点互相找不到ES集群的节点之间靠发现机制discovery找到彼此。早期版本用的是多播现在主流是单播也就是在配置文件里告诉节点你的同伴们住在哪些地址。# elasticsearch.yml discovery.seed_hosts: - 192.168.1.10 - 192.168.1.11 - 192.168.1.12这段配置的意思是节点启动后尝试连接这三个地址把它们加入自己所属的集群。这里有个容易被忽略的坑必须加上初始主节点的配置否则集群永远选不出master日志里全是master not discovered yet的报错。cluster.initial_master_nodes: - node-1 - node-2 - node-3注意这个配置只对集群首次启动有用。首次选举出master之后正常情况就不需要它了但如果你在集群运行中加了新节点新节点上依然是靠discovery.seed_hosts找到master并加入集群。所以从习惯上我建议每次都保留这两段配置省得以后扩节点时还要去改。2.3 脑裂问题一个集群分裂成两个独立王国脑裂split brain是分布式系统里最经典、也最致命的故障之一。简单说由于网络抖动或GC暂停部分节点和master临时失联这些节点会认为master挂了于是自己发起新一轮master选举——结果就是集群里同时出现两个master各管一摊分片数据写入时就可能发生冲突等你发现的时候数据已经乱了。ES解决脑裂的手段是**法定人数quorum**机制一个节点想成为master必须获得超过半数可投票节点的支持。具体配置是discovery.zen.minimum_master_nodes: 2 # 老版本 cluster.election.maximum_master_nodes: 2 # 新版本这个数值算起来很简单master候选节点数 / 2 1。在三节点集群里就是2在五节点集群里就是3。我见过有人图省事直接给3个节点配了1结果就是集群一抖动就重新选主整个集群抖成筛子。这是ES集群运维里最经典的坑没有之一。注意从ES 7.x开始minimum_master_nodes被默认配置为自动维护日常不用手动改。但了解它的原理仍然必要因为当你手工扩展或缩容节点时自动配置不一定符合你的预期理解背后的决策逻辑能让你在日志里看到投票结果时心里有底。3. 三节点集群搭建实操从配置到验证的完整流程理论部分就到这接下来动手。我的环境是三台CentOS 7的虚拟机内存各8G磁盘各100GIP分别是192.168.1.10/11/12。ES版本用7.10.0这个版本稳定坑少社区资料也多。3.1 环境准备JDK版本和系统参数缺一不可ES 7.10要求JDK 11以上。推荐用ES自带的JDKtar包解压后里有jdk目录省得自己配Java环境变量还能避开系统JDK版本太新或太旧导致的莫名故障。# 解压ES tar -zxvf elasticsearch-7.10.0-linux-x86_64.tar.gz mv elasticsearch-7.10.0 /usr/local/es然后必须修改系统参数因为ES对系统资源的要求很苛刻默认配置肯定会被它嫌弃# /etc/security/limits.conf 追加 esuser soft nofile 65536 esuser hard nofile 65536 esuser soft nproc 4096 esuser hard nproc 4096 # /etc/sysctl.conf 追加 vm.max_map_count262144 sysctl -p # 使其生效max_map_count这个参数是针对内存映射区的限制ES底层大量使用mmap默认值太低会导致启动时报max virtual memory areas vm.max_map_count [65530] is too low。我在这上面吃过亏配好三个节点重启后才发现有一个节点没生效排查了半天。还有一点绝对不能用root用户跑ES。ES出于安全考虑明确拒绝root启动。创建一个专用用户useradd esuser chown -R esuser:esuser /usr/local/es su esuser3.2 核心配置逐项解析这是最关键的一步直接给配置然后解释每一项的用途# node-1 的 elasticsearch.yml cluster.name: my-es-cluster node.name: node-1 node.roles: [master, data, ingest] path.data: /data/es/data path.logs: /data/es/logs network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: - 192.168.1.10 - 192.168.1.11 - 192.168.1.12 cluster.initial_master_nodes: - node-1 - node-2 - node-3cluster.name集群的名称三个节点必须完全一致否则它们会认为彼此属于不同集群永远合不到一起。node.name节点标识必须唯一。建议起有意义的名字不然排查问题时满屏node-1、node-2你也分不清谁是谁。path.data和path.logs数据目录和日志目录。千万别放在默认的/tmp下因为Linux会周期性清理/tmp目录我就见过有人的数据目录被清掉后集群直接瘫痪不得不从备份恢复。network.host这里写0.0.0.0表示监听所有网卡。注意如果这里配了非loopback地址ES会自动切换到生产模式对bootstrap检查等要求会更严格这时候你的系统参数要是没配好就起不来。transport.port节点间内部通信端口默认9300。这个是集群内部通信用的和HTTP端口9200要区分开。第2台和第3台配置一样只需改node.name为node-2、node-3。配置别的不用动。3.3 启动集群和验证确认配置无误后在三个节点分别执行启动命令# 这里提权是ES推荐的启动方式可以先验证一下配置有没有问题 /usr/local/es/bin/elasticsearch -d -p /tmp/elasticsearch.pid-d表示后台运行-p用来记录PID文件后面停止服务时可以用kill $(cat /tmp/elasticsearch.pid)。日志在/data/es/logs/my-es-cluster.log里启动出错时先看这个。最常见的两个问题报failed to bind to [9300]——检查一下端口占用或者三台机器的防火墙没放行9300端口。报master not discovered——三种情况cluster.initial_master_nodes没配置或写错节点名、discovery.seed_hosts的地址写错、三台机器的cluster.name不一致。启动完验证curl -X GET http://192.168.1.10:9200/_cluster/health?pretty理想的返回是{ cluster_name: my-es-cluster, status: green, number_of_nodes: 3, active_primary_shards: 0, active_shards: 0 }看到status为green、number_of_nodes为3说明集群心脏在跳。如果你看到的是yellow也别慌可能是索引没有副本分片导致的后面创建索引时加上副本就能变绿。3.4 集群故障转移验证手动杀节点看ES的反应集群搭完了不做一次故障演练就说不过去了。我的习惯是kill掉一个data节点观察集群能不能自动把分片迁移到别的节点上这也顺手检验一下分片设计得对不对。kill -9 $(cat /tmp/elasticsearch.pid) # node-1然后每隔几秒查询一次集群健康状态curl -X GET http://192.168.1.11:9200/_cluster/health?pretty你会看到状态先是yellow——因为有一个节点掉线了部分副本分片暂时不能分配。与此同时集群会自动把掉线节点上的分片在其他节点上重新创建。等几十秒到几分钟取决于分片大小和磁盘速度状态会回到green。这个过程的细节非常值得关注master节点重新分配分片时I/O 和 CPU 都会明显拉高。这直接证明了为什么集群规划时至少要留出30%-40%的余量不能把磁盘打到90%以上——否则节点故障后的自动迁移可能因为资源不足而失败故障就真的成灾难了。4. 分片机制拆解索引设计的底层逻辑集群搭好之后下一个绕不开的问题是分片。很多人把分片当成了一种存储选项想用就用、不想用就不用。实际上分片是ES数据分布和并行的根本机制理解它直接决定你的索引设计质量。4.1 分片到底是什么主分片和副本分片的关系ES的一个索引逻辑上就是一个完整的表物理上却被切成若干块每一块就是一个主分片primary shard。每个主分片还可以有若干副本分片replica shard副本是主分片的完整拷贝作用是高可用和分摊查询压力。这里的关键点是写入请求只会到主分片由主分片负责同步给副本。读请求可以走副本所以副本越多查询吞吐量越大。主分片数量在索引创建后不可修改——想改只能重建索引这一点你必须趁早想清楚。用生活里的类比主分片好比一个仓库里的实体货架副本分片是这些货架的拍照备份。实体货架的数量决定了仓库能摆多少货并且一旦定了就不能改而照片备份没了可以再洗不影响仓库容量只是取货时会可能出现等照片的情况。4.2 分片数量怎么定公式、权衡和反直觉的结论主分片数量到底设多少我建议套这个思路来算预估你的最终数据总量。单个分片的数据量建议控制在20GB到50GB之间。这个是经验值范围低于这个可以超出这个查询和merge压力会显著上升。主分片数量 预估数据总量 / 单分片合理容量。比如你预估最终数据有200GB那主分片设5到10个都可以。不要贪多分片太多了反而拖慢查询也不要太少少了数据挤在一起性能上不去。有一个反直觉的结论需要强调主分片多不代表查询快。查询时ES会把请求广播到所有分片并行执行再合并结果。分片过多会导致调度开销变大、合并结果变慢反而让查询变慢。很多人一上来就建30个主分片数据量却只有几GB就是典型的过犹不及。副本分片的数量则按需调整读多写少的场景可以设为2或更多写入密集的场景设1就够——否则写一条数据要同步给多个副本写入延迟会被拉高。4.3 分片不均匀数据倾斜的实战案例我干过一件蠢事说出来给大家当反面教材。当时给日志索引设置了10个主分片不设副本跑了一周后发现某几个分片涨到40GB另外几个只有10GB。查询延迟从100毫秒涨到1秒多ESSlowlog里全是超时记录。排查过程是这样的先看每个分片的大小——curl -X GET http://192.168.1.10:9200/_cat/shards/my-index?vhindex,shard,prirep,store,node输出里明显能看到store列的数值差距。再逐个节点看磁盘占用确认不是某个节点机器问题而是分片本身的数据量分配不均。问题根子在于我的索引使用了自定义的路由字段routing而路由值的分布本来就不是均匀的——某些用户的数据量天然就多。ES默认按_id哈希路由可以整套避开这个问题但我当时为了按用户隔离查询强行指定了路由键于是把一个分片变成了热点。解决方向是重建索引优化路由策略比如换成按用户ID的哈希值再取模并配合冷热节点架构来转移压力保证数据尽量均匀分布。所以你现在问我分片设计的原则我只会说一句话不要让任何单一维度天然形成热点。4.4 分片的生命周期rollover与ILM当你开始认真对待分片迟早会碰到索引的滚动管理问题。ES提供了一整套索引生命周期管理ILM机制核心是让索引按条件自动滚动PUT _ilm/policy/log_policy { policy: { phases: { hot: { actions: { rollover: { max_size: 50gb, max_age: 30d } } } } } }这个策略的意思是当索引超过50GB或者存在超过30天后自动创建一个新索引把写入流量切过去。配合索引模板使用新索引自动套用分片数和别名设置PUT _index_template/log_template { index_patterns: [logs-*], template: { settings: { number_of_shards: 5, number_of_replicas: 1, routing.allocation.include.size: hot } } }这套机制的好处是你不再需要手动预估索引规模也不用操心数据满了怎么办。我建议所有日志类场景、时序类场景都直接上ILM省心。但要注意ILM只负责滚动不负责删除——冷数据删不删、怎么删你需要自己在策略里配delete阶段。5. MySQL数据同步到ES三种方案选型与实战集群和分片都搞清楚了现在来到第三个坎把MySQL的数据同步进ES。这可能是日常开发里最接地气的需求——你有一张用户表、订单表、文章表需要提供站内搜索或复杂筛选。5.1 三种主流方案对比Logstash、Canal、自研同步先说说市面上的答案。围绕MySQL同步到ES主流方案大致三条路方案原理优点缺点Logstash JDBC定期轮询MySQL全量或按时间戳增量拉取数据配置简单ES官方配套适合全量或粗粒度同步无法感知MySQL的delete操作增量依赖业务字段如update_timeCanal 消息队列伪装成MySQL从库订阅binlog将变更事件转发给ES实时性强能感知增删改适合对实时性要求高的场景架构复杂需要额外部署Canal、MQ等组件运维成本高自研同步任务用代码定时/实时同步或监听业务事件触发灵活可控能完全贴合业务开发量大边界情况多容易出bug我个人的建议是初期或者数据量不大直接上Logstash。它配置简单能快速见效。等业务量上来、对实时性要求高了再演进到Canal方案。理由有两个第一Logstash的定时轮询对数据量小的表百万级以内完全够用同步延迟能控制在分钟级第二它的全量增量逻辑天然支持不需要你从头写状态维护的代码。5.2 实战用Logstash把MySQL表全量增量同步进ES这块我直接给出一个能复制的流程。我的测试场景是一张文章表article大约80万行数据结构简化如下CREATE TABLE article ( id bigint(20) NOT NULL, title varchar(255) DEFAULT NULL, content text, status tinyint(4) DEFAULT 1, update_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;第一步准备Logstash的配置文件。新建mysql-sync.confinput { jdbc { jdbc_driver_library /usr/local/logstash/lib/mysql-connector-java-8.0.22.jar jdbc_driver_class com.mysql.cj.jdbc.Driver jdbc_connection_string jdbc:mysql://192.168.1.100:3306/testdb?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jdbc_user es_sync jdbc_password your_password statement SELECT id, title, content, status, update_time FROM article WHERE update_time :sql_last_value use_column_value true tracking_column update_time tracking_column_type timestamp schedule * * * * * last_run_metadata_path /data/logstash/conf/last_run } }几个关键点我要逐条讲tracking_column指定增量同步的追踪字段通常是记录更新时间的update_time。use_column_value设为true表示使用这个字段的值来判断哪些行需要同步。schedule是Cron表达式* * * * *表示每分钟执行一次。如果你不需要太实时改成5分钟一次也可以。last_run_metadata_path保存上一次同步到的update_time值。这样每次重启Logstash后增量位置不会丢。这里有一个大坑如果当天更新了很多数据且update_time用的是MySQL的datetime类型跨时区时容易差8小时。连接串里要显式指定serverTimezoneAsia/Shanghai两边都用同一时区。第二步配置filter和outputfilter { mutate { rename { id article_id } remove_field [version, timestamp] } } output { elasticsearch { hosts [192.168.1.10:9200, 192.168.1.11:9200, 192.168.1.12:9200] index article_index document_id %{article_id} user elastic password changesme } }document_id直接映射MySQL主键这是幂等更新的关键同一行数据重新同步时会覆盖不会产生重复文档。这个设计一定要坚持。第三步首次跑全量。上面那段增量配置是跑不了全量的因为update_time :sql_last_value在第一次执行时只能把update_time大于1970年1月1日的数据捞出来值太小了也可能导致全量捞不出来。我这里的处理是额外准备一个全量配置文件或者干脆在第一次全量后把last_run_metadata_path文件里的值初始化成你想要的全量起点# 初始化last_run只同步近7天数据 echo --- 2024-01-01 00:00:00 /data/logstash/conf/last_run全量同步时我建议分页拉取避免一次性加载80万行把Logstash的堆撑爆。JDBC input支持自定义SQL也可以配合jdbc_page_size参数控制批次。jdbc_paging_enabled true jdbc_page_size 50005.3 又一个坑MySQL的delete操作Logstash感知不到这是Logstash方案最大的硬伤。业务里删了MySQL的一行数据ES里那条文档不会自动消失——你搜出来的结果就成了查无此源的脏数据。我实际项目里的处理方法是业务层做软删除。表里加一个deleted字段删除时不真删只把这个字段置为1。同步时SQL里加上条件SELECT id, title, content, status, update_time FROM article WHERE update_time :sql_last_value AND deleted 0同时在ES侧建立针对删除的兜底清理如果deleted字段为1同步时把文档删除filter { if [deleted] 1 { mutate { add_field { [metadata][action] delete } } } }如果你没法改表结构就得考虑Canal方案了。Canal通过解析binlog能拿到删除主键然后调用ES删除接口这是真正“物理删除实时同步”的唯一成熟路径。5.4 进阶Canal Kafka Logstash的实时同步架构当数据量和实时性要求同时上来时我推荐这套组合Canal监听MySQL的binlog变更发送到KafkaLogstash消费Kafka消息写入ES。架构看起来多了一层但每个组件各司其职压力分散。Canal负责实时捕获数据库变化Kafka负责削峰和缓冲Logstash只做格式转换和ES写入。数据库变更的洪峰来了Kafka能兜住不会压垮ES。Canal部署后的一个核心配置样例# canal.properties canal.serverMode kafka kafka.bootstrap.servers 192.168.1.20:9092,192.168.1.21:9092,192.168.1.22:9092Logstash对应配置input { kafka { bootstrap_servers 192.168.1.20:9092,192.168.1.21:9092,192.168.1.22:9092 topics [article_topic] codec json } } output { elasticsearch { hosts [192.168.1.10:9200, 192.168.1.11:9200] index article_index document_id %{id} } }这套架构部署起来比Logstash单机方案复杂得多但换来的是秒级延迟和更强的抗流量能力。我的经验是数据量超过千万级或者业务对搜索结果的时效性要求是分钟以内直接考虑Canal方案别犹豫。Logstash轮询方案的延迟和能力上限到那个规模一定会让你回头重写。6. 整个链路的性能排查思路最后写一点实战排查经验。三节点集群、分片、MySQL同步这些都跑起来之后你一定会遇到到底哪里慢了的问题。这个问题的排查思路很多人没走对。先定一个总原则从端到端切割沿着链路逐段打点。一次完整的ES写入链路由生产端、网络、ES集群三部分组成任何一段出问题都会表现为写入慢。我从一个真实的线上问题说起。当时项目反馈ES写入高峰期频繁超时日志里时不时报Elasticsearch health check failed。我当时是按这个顺序排查的第一步确认集群本身状态。调用_cluster/health看状态和未分配分片数量再调_cat/nodes?v看每个节点的CPU、堆内存使用率和负载。这里有个细节在几毫秒内连续调用几次观察数据变化幅度而不是只看单次值——单次采样看不出问题趋势才有效。第二步检查写入线程池是否堆积。ES的写入是异步线程池模型curl -X GET http://192.168.1.10:9200/_cat/thread_pool/write?vhnode_name,name,active,queue,rejectedrejected这个值特别关键——如果大量请求被拒绝说明写入压力已经超过集群承载能力再查下去就是找瓶颈在哪一台节点上了。第三步看慢日志。ES有专门的索引慢日志PUT /article_index/_settings { index.search.slowlog.threshold.query.warn: 500ms, index.search.slowlog.threshold.fetch.warn: 300ms, index.indexing.slowlog.threshold.index.warn: 500ms }设置完之后超过阈值的请求会记录在logs/es_index_search_slowlog.log里。通过慢日志里的shard编号你能定位是哪个分片慢。如果集中在一两个分片大概率是数据倾斜如果所有分片都慢就要看磁盘I/O和CPU了。第四步区分磁盘问题还是CPU问题。在节点上执行iostat -x 1看util参数如果持续90%以上磁盘就是瓶颈。同时看ES的JVM GC日志——如果出现频繁的Full GC那瓶颈在堆内存。磁盘慢和CPU过载是两个完全不同的调优方向前者要扩磁盘或降副本后者要增加节点或调大批量写入窗口。这个区分做错调优就是一个瞎忙的大动作。关于排查我把一个常用的定位顺序总结成这四步遇到问题按顺序来基本都能找到方向集群健康是否红/黄节点负载CPU、内存、I/O是否失衡线程池和队列写入、搜索线程是否有拒绝分片分布与慢日志是否热点集中7. 一些能直接落地的小建议写到最后串一串这三件事在实际项目中应该怎么配合。版本选择上ES 7.10是我目前比较推荐的稳定版本和MySQL同步的JDBC驱动选8.0.x及以上Logstash版本要和ES大版本对齐不要一个7.x一个8.x混着用配置格式会有兼容问题。三节点集群的分片设计我给个默认起步值日志类数据用3主分片1副本业务类数据用5主分片1副本然后靠ILM滚动控制单分片大小在50GB以内。这套配置在大多数场景下是安全的选择后续容量涨了再扩副本比改分片容易得多。MySQL同步的演进路径我建议按业务时效性来决策时效性要求不在于分钟级比如商品搜索、文章搜索直接Logstash定时同步一个月后再考虑要不要升级时效性要求在秒级比如订单状态的实时可见、运营后台的实时报表一开始就上Canal。架构选择回头改的代价很大一开始就选对路最省钱。最后我想说ES不是一个配置完就完事的东西它是一个需要持续观察、持续调优的系统。集群搭好了只是开始分片和同步的设计同样要跟着数据量成长不断修正。你踩的那些坑——不管是节点互相找不到、分片数据倾斜还是同步丢数据——最后都会变成你对这套系统真正的理解。你搭的每一个集群都会成为你下一套集群的经验底气这就是这个领域积累的真相。