solr集群中配置文件是经常更新的，频率最高的也就是schema.xml和solrconfig.xml这两个配置文件了，对于更新配置文件之前，我们先了解一下集群项目结构
由于在集群模式下，solrconfig.xml和schema.xml等配置文件都由Zookeeper集群管理，所以本地项目中只保留单一shard分片，各个collections分片保存位置是solr根目录下的server/solr/下，这个目录下有一个solr.xml文件，然后可以随便进入一个shard目录，可以看到只有一个data目录和一个core.properties文件，其中data目录存放solr备份的索引数据、core.properties文件通过vim编译可以看到这里面保存了shard序号，collections名称，核子节点的名称等等；另外官方文档也给出了对应的solrcloud本地的目录结构：
solr.xml
core_name1/
core.properties
data/
core_name2/
core.properties
data/
这种结构和我们看到的是一样的
根据以上的目录结构，所以我们更新配置必须将配置文件更新到Zookeeper集群才可以正常生效，之前在网上查过一些资料，好多都是无效或者过时的，用过一段时间的一个方法就是，首先登录zookeeper，删除原有的schema.xml文件，然后进行配置的上传，上传完成后并不是立即生效的，所以要依次重启solr集群，首先说明这个方法是有效的，但是感觉太麻烦；另外由于生产过程中，随便重启solr服务就和重启服务器一样会造成一定的损失或者风险，所以这种方式明显不合理，尽管我们一直在使用；实际上最好的解决方法在官方文档已经给出了，这个需要我们自己慢慢探索，这里解决方法如下：
比如我们修改schema.xml配置文件之后，根本不用登录zookeeper删除原有文件，文件会自动覆盖，这里直接上传即可，命令如下：
./server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd putfile /solr/configs/my_config/schema.xml ../configs/conf/schema.xml
参数putfile指定配置文件在zookeeper上的绝对路径，这里注意是配置的路径，不是collection的路径，二者名称不相同，后面跟的是修改之后本地schema.xml配置文件的路径
上传文件之后，我们通过solr admin管理界面都可以看到文件内容更新了，有2种方法可以查看到
但是我们去Update、Query时会出错，浏览Schema字段时没有更新，很明显配置没有生效；接下来就是最重要的一步，我们找到官方文档的collections API位置，可以看到有一个如下的API：
RELOAD这个API就是重新加载collection，不用重启solr，点击锚点可以看到具体使用解释如下：
可以看到解释的很清楚了，经过上一步更新覆盖了配置文件之后，我们只需要curl或者访问以下链接即可：
http://localhost:8983/solr/admin/collections?action=RELOAD&name=my_collection
访问之后，返回success，就重新加载核心成功了，全部正常使用
以上对于更新collections配置文件的这个过程其实也是解决问题的一个过程，首先我们应该充分理解我们使用的工具或者框架具体是做什么的或者说哪方面是有优势的，以及更深的实现机制和原理，多去对比，这样遇到问题的时候才可以做到知道这个问题而不会不知所措；另外有些地方不合理，是为什么不合理，会给生产带来哪些不好的影响以及潜在的风险；然后带着这些问题去搜索，建议查看官方文档，特别是大数据方面直接在搜索引擎搜索出来的结果大多是互相抄袭、过时、甚至错误的，这个时候就要充分的去品味官方文档中的解释，然后去自己思考，这样慢慢的自己的知识就健全了，慢慢的自己的内功也就提升了，相对来说也就慢慢的进入了高手的行列；对于初学者不知所措是很正常的，个人认为重要的还是坚持锲而不舍的研究，只有这样才可以跟随技术的进步
最后在学习工作中，总结一句话就是：永不放弃、知其然知其所以然、授人以鱼，不如授之以渔