不爲也 比不能也

Many settings in Elasticsearch are dynamic and can be modified through the API. Configuration changes that force a node (or cluster) restart are strenuously avoided. And while it’s possible to make the changes through the static configs, we recommend that you use the API instead.Elasticsearch의 많은 설정은 동적이고, API를 통해 변경될 수 있다. node나 cluster를 강제로 다시 시작해 구성을 변경하는 것은 절대로 피해야 한다. 그리고, 정적 구성을 통해 변경하는 것도..

Elasticsearch emits a number of logs, which are placed in ES_HOME/logs. The default logging level is INFO. It provides a moderate amount of information, but is designed to be rather light so that your logs are not enormous.Elasticsearch는 ES_HOME/logs 에 많은 로그를 출력한다. 기본 로깅 수준은 INFO 이다. 그것은 적당한 양의 정보를 제공하지만, 로그가 많지 않도록 오히려 가볍게 설계되었다.When debugging problems, particularly problems with node discovery..

If you are in an indexing-heavy environment, such as indexing infrastructure logs, you may be willing to sacrifice some search performance for faster indexing rates. In these scenarios, searches tend to be relatively rare and performed by people internal to your organization. They are willing to wait several seconds for a search, as opposed to a consumer facing a search that must return in milli..

As discussed way back in Scale Horizontally, Elasticsearch will automatically balance shards between your available nodes, both when new nodes are added and when existing nodes leave.Scale Horizontally에서 이야기했던 것으로 돌아가 보면, 새로운 node를 추가하거나 기존의 node가 제거되면, Elasticsearch는 자동으로 활용할 수 있는 node간의 shard 균형울 맞추려 한다.Theoretically, this is the best thing to do. We want to recover missing primaries by promot..

There will come a time when you need to perform a rolling restart of your cluster—keeping the cluster online and operational, but taking nodes offline one at a time.cluster를 차례대로 재 시작(cluster는 온라인이고 동작을 하는 상태로 유지하면서, node를 차례로 오프라인으로 하는)해야 할 경우가 있을 것이다.The common reason is either an Elasticsearch version upgrade, or some kind of maintenance on the server itself (such as an OS update, or hardware..

As with any software that stores data, it is important to routinely back up your data. Elasticsearch replicas provide high availability during runtime; they allow you to tolerate sporadic node loss without an interruption of service.데이터를 저장하는 모든 S/W와 마찬가지로, 데이터를 정기적으로 백업하는 것은 중요하다. Elasticsearch의 replica는 실행 시간 동안 고 가용성을 제공하고, 서비스의 중단 없이, 돌발적인 node 손실을 극복할 수 있다.Replicas do not provide protection..

Once you’ve backed up some data, restoring it is easy: simply add _restore to the ID of the snapshot you wish to restore into your cluster:어떤 데이터를 백업했다면, restore은 매우 쉽다. 단순히, cluster에 restore하려는 snapshot의 ID에 _restore 를 추가하면 된다.POST _snapshot/my_backup/snapshot_1/_restoreThe default behavior is to restore all indices that exist in that snapshot. If snapshot_1 contains five indices, all five will..

Once you get a cluster into production, you’ll find that it takes on a life of its own. Elasticsearch works hard to make clusters self-sufficient and just work. But a cluster still requires routine care and feeding, such as routine backups and upgrades. 제품에 cluster를 적용하면, 저절로 운영되는 것을 볼 수 있다. cluster가 혼자서 그냥 동작 할 수 있도록, Elasticsearch는 최선을 다해 작동한다. 그러나, cluster는 여전히 일상적인 백업이나 업그레이드 같은 일반적인 관리를 필요로..