ChatGPT在这里技术上是正确的。但它的答案需要一些澄清。首先，代码200仅在您更新现有文档时返回。当第一次创建具有给定ID的文档时，您会返回201。
但是撇开技术细节不谈，假设你指的是2xx范围代码，答案是肯定的，当且仅当主服务器开始处理请求时，不是所有的副本都可用。主分片检查哪些副本可用，并将等待所有这些副本上的复制完成。如果不是所有副本都可用，rules可以通过你链接的index.write.wait_for_active_shards设置进行配置。这就是为什么你必须坚持“确保elasticsearch至少有2个数据节点”。如果你只有一个节点，你会从一个主节点得到2xx响应，这将回答你的问题。
我认为你正在寻找的行为是重复的。它在v2.0.0之前的elasticsearch中可用。然而，后来被删除，因为它弊大于利，并阻止了团队实现新的创新功能。打开异步复制并不能解决服务器吞吐量的问题。服务器仍然必须完成相同的工作量，如果它们不能跟上，无论如何，最终都会让一切变慢。所以，无论你目前在性能上遇到什么问题，都需要用其他方式来解决。

除了@imotov的伟大回答之外，async replication was removed在2.0中毫无价值，因为它与其他功能（如index sealing）冲突。

**如果你不愿意等待副本确认，为什么一开始就有副本呢？**由于您的首要任务是改进indexing performance，因此您的情况要好得多，只需删除所有副本并在发送批量调用之前将刷新间隔设置为-1，这将带来比其他任何方法都更好的性能改进，特别是因为你说你知道这可能会导致数据丢失。

当然，您还需要根据您的硬件（即RAM、CPU、节点数量、磁盘等）调整批量批量大小。默认设置可能不是最适合您的，请始终调整以获得最佳性能。
如果您使用的是Logstash，请确保使用集群所能容纳的worker。如果您的节点在此期间专门用于索引数据，请不要犹豫，增加索引缓冲区（最大为512 mb）。
总之，您可以调整许多旋钮来提高索引性能，但在这种情况下，如果仍然可用，那么JDBC复制肯定不会对您有太大帮助。