But this is not a common way to do so, I mean, nobody want to ADDREPLICA after collection was created.
Erick Erickson <erickerick...@gmail.com> 于2018年8月28日周二 下午1:24写道： > Every _replica_ can point to a different disk. When you do an > ADDREPLICA, then you can supply whatever path to the data > you desire. And you can have as many replicas per Solr instance > as makes sense. > > Best, > Erick > On Mon, Aug 27, 2018 at 8:48 PM zhenyuan wei <tins...@gmail.com> wrote: > > > > @Christopher Schultz > > So you mean that one 4TB disk is the same as four 1TB disks ? > > HDFS、cassandra、ES.... can do so, multi data path maybe maximize indexing > > throughput in same cases. > > click links > > <https://www.elastic.co/blog/elasticsearch-performance-indexing-2-0> > with > > some explain > > > > > > Christopher Schultz <ch...@christopherschultz.net> 于2018年8月28日周二 > 上午11:16写道： > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA256 > > > > > > Shawn, > > > > > > On 8/27/18 22:37, Shawn Heisey wrote: > > > > On 8/27/2018 8:29 PM, zhenyuan wei wrote: > > > >> I found the “solr.data.dir” can only config a single directory. > > > >> I think it is necessary to be config multi dirs，such as > > > >> ”solr.data.dir:/mnt/disk1,/mnt/disk2,/mnt/disk3" ， due to one > > > >> disk overload or capacity limitation. Any reason to support why > > > >> not do so？ > > > > > > > > Nobody has written the code to support it. It would very likely > > > > not be easy code to write. Supporting one directory for that > > > > setting is pretty easy ... it would require changing a LOT of > > > > existing code to support more than one. > > > > > > Also, there are better ways to do this: > > > > > > - - multi-node Solr with sharding > > > - - LVM or similar with multi-disk volumes > > > - - ZFS surely has something for this > > > - - buy a bigger disk (disk is cheap!) > > > - - etc. > > > > > > - -chris > > > -----BEGIN PGP SIGNATURE----- > > > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > > > > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluEvn8ACgkQHPApP6U8 > > > pFgTTg//ayed4AXtocVrB6e/ZK0eWz5/E1Q7Oa7kF0c34l0MH6BIe4iOHDmrR+J9 > > > A+t6SzVQqURMrDE8plg/xbPTlyGF8wGrEjZUZF4fpWlgnY/qNYxl5S9zJ1hPgBh7 > > > fCKkb+LuLGdZMM4oORfCYtMgpDjOnLihHmDTfkrvZzyZwOQGeFpgEZDZKFYAjcur > > > wqIGTMTTWfSCoPQgQzvI8Husq7Rs75BEc+mAkaPOL0LvT9PQDEPEXXt3Kf5vXgM+ > > > Eet1ymltZM/Xz+V/em/oeumCoCE18uxi9seuDhTpHRLjS9tCBbPWA0NmobriY3ct > > > GskwCnsFDAeGjG/7dcA/zmB8BK4t6JpUvI+OcJU5dvQczpQbhB9WT4GQUiME9Tvr > > > RjBES53HoEEKA8gb0kiuPN1pE2MSX8vO3uKpQtzVS2MOmuOeV/IebrnP/zLTll18 > > > awtWWbPmzaAGAUfXL2ExK0+ism0o31i46CNfLfBBM8jh3lkc2HNdz5TLe8YfN3Sp > > > Tj0HfmYynhtH1CggOAcI1M4PIEbIGfoywX/ICSGHnLwfQoDUnBmjqXhGkFUIstWk > > > Dcntx+4E4NRny6zDZfg5UMjWYyo+fOVSoaDf6dfgBWIB1I3xPn5Dt0In7+oRtZ9i > > > Xlkw6DSaSZZ5caBqjaF278xj7IwEw2zipLPWB7hVCcUhKuJBbDY= > > > =rbrT > > > -----END PGP SIGNATURE----- > > > >
