从5.0开始，solr采用了自动发现模式（discovery，区别于传统模式legacy），Solr会自动找到安装目录中、或solr_home中的配置文件：core.properties，并根据里面的name属性来初始化相对于的core。solr.xml中仍然会定义一些配置参数，但是core本身不会定义在这个文件中。
Solr会递归搜索所有solr和solr_home目录和子目录，当在一个目录中发现core.properties后，就停止搜索当前目录的所有子目录，转向下一个同级目录搜索。所以，下面两个配置只有第一个生效：./cores/core1/core.properties./cores/core1/coremore/core5/core.properties而下面三个配置，都会生效：./cores/somecores/core1/core.properties./cores/somecores/core2/core.properties./cores/othercores/core3/core.properties
一个core.properties文件代表一个core。文件的内容可以是空的，这个时候，solr会把该文件所在的目录作为name，比如跟./cores/core1/core.properties对应的core name就是core1；instanceDir就是./cores/core1；dataDir就是./cores/core1/data，等等。
core.properties配置参数：
name：SolrCore的名字config：该core的配置文件名字，缺省是solrconfig.xmlschema：schema文件的名字，缺省是schema.xmldataDir：索引文件的存放位置，相对于instanceDir的相对路径，缺省是“data”configSet：configSet的名字properties：该core的额外属性文件的路径和名字，可以是绝对路径、或相对于instanceDir的相对路径transient：如果是true，当solr达到transientCacheSize这个限定时，这个core会被卸载（unload）；缺省是false，即使用LRU原则卸载。SolrCloud模式下true是不推荐的loadOnStartup：缺省是true，就是在solr启动的时候启动该core。SolrCloud模式下false是不推荐的coreNodeName：只在SolrCloud的情况下使用，是这个replica所在的node的标识。这个名字缺省是自动生成的。这个配置的名字可以在以后需要替换一个自动生成的名字的时候使用，比如使用一个新机器（新的hostname和port）替换一个坏机器的时候ulogDir：存放update log的绝对或相对路径（SolrCloud）shard：这个core所归属的shard（SolrCloud）collection：这个core所属的collection名字（SolrCloud）
roles：SolrCloud的一个保留参数，未来可能会用到，或用户用了做一些自己的标记 另外，用户还可以定义自己的属性，以作为其他配置文件的变量。
solr.xml配置标签：<solrcloud/>：定义几个跟SolrCloud相关的参数，当solr启动参数带有-DzkRun 或 -DzkHost时，这个标签才生效<logging/>：定义跟日志相关的配置参数<shardHandlerFactory/>：配置自定义的shard handler
Config Sets：在multicore的solr实例中，可以利用config set来提供统一的配置文件给各个core共享。这个可以通过在configSetBaseDir目录下创建一个目录来实现，该目录的结构如下： /<configSetBaseDir> /configset1 /conf /schema.xml /solrconfig.xml /configset2 /conf /schema.xml /solrconfig.xml 缺省的configSetBaseDir就是$SOLR_HOME/configsets，也可以在solr.xml中指定这个目录。
非SolrCloud模式下，可以通过CoreAdmin API，把configset作为参数来创建一个新的core，比如： http://<solr>/admin/cores?action=CREATE&name=mycore&instanceDir=path/to/instance&configSet=configset2
如果是SolrCloud模式下，配置信息是从zookeeper数据库中获取的。
