What I've noticed is after my cluster (0.19.12) has been running for a few
days, trying to create a brand new index fails with an index already exists
exception. This is a brand new index, with a different, unique name. The
"type" is the same. So I might have:
index_a, type book mapping
index_b, type book mapping
then I try to create index_c, type book mapping, and get an index already
exists exception. Using the "head" plugin, I see the index gets created,
but it exists in a funky state. The primary seems OK, but the replica is
"unassigned".
During this time, "head" reports the cluster as red. But queries against
existing indexes seem OK.
I manually delete the bad index_c then restart the cluster. Now my code can
create index_c. A few minutes later, it can also create index_d.
Only thing that seems consistent is that the cluster
has been running for at least a few days. It's like after a few days the
cluster has some issues?
restarting the cluster solves the issue
Obviously I don't want to restart the cluster because I'm trying to
automatically create these indexes....
You might have had a split-brain scenario where different nodes in the
cluster were forming sub-clusters. How many nodes do you have and what is
your replica count for those indexes?
What I've noticed is after my cluster (0.19.12) has been running for a few
days, trying to create a brand new index fails with an index already exists
exception. This is a brand new index, with a different, unique name. The
"type" is the same. So I might have:
index_a, type book mapping
index_b, type book mapping
then I try to create index_c, type book mapping, and get an index already
exists exception. Using the "head" plugin, I see the index gets created,
but it exists in a funky state. The primary seems OK, but the replica is
"unassigned".
During this time, "head" reports the cluster as red. But queries against
existing indexes seem OK.
I manually delete the bad index_c then restart the cluster. Now my code
can create index_c. A few minutes later, it can also create index_d.
Only thing that seems consistent is that the cluster
has been running for at least a few days. It's like after a few days
the cluster has some issues?
restarting the cluster solves the issue
Obviously I don't want to restart the cluster because I'm trying to
automatically create these indexes....
I have 2 master nodes, 2 data nodes. I set replica count to 1. I was
concerned with the split-brain issue, so I did set
discovery.zen.minimum_master_nodes: 2
in the conf files for master and data nodes. Figured if network
partitioned, then I would get some other error, like "not enough masters."
-T
On Saturday, August 24, 2013 12:15:45 PM UTC-7, Ivan Brusic wrote:
You might have had a split-brain scenario where different nodes in the
cluster were forming sub-clusters. How many nodes do you have and what is
your replica count for those indexes?
Cheers,
Ivan
On Sat, Aug 24, 2013 at 12:09 PM, Tinou Bao <tino...@gmail.com<javascript:>
wrote:
What I've noticed is after my cluster (0.19.12) has been running for a
few days, trying to create a brand new index fails with an index already
exists exception. This is a brand new index, with a different, unique name.
The "type" is the same. So I might have:
index_a, type book mapping
index_b, type book mapping
then I try to create index_c, type book mapping, and get an index already
exists exception. Using the "head" plugin, I see the index gets created,
but it exists in a funky state. The primary seems OK, but the replica is
"unassigned".
During this time, "head" reports the cluster as red. But queries against
existing indexes seem OK.
I manually delete the bad index_c then restart the cluster. Now my code
can create index_c. A few minutes later, it can also create index_d.
Only thing that seems consistent is that the cluster
has been running for at least a few days. It's like after a few days
the cluster has some issues?
restarting the cluster solves the issue
Obviously I don't want to restart the cluster because I'm trying to
automatically create these indexes....
Any ideas?
-T
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
Realize that the master nodes publish to a virtual IP while the data nodes
servers are not setup with any virtual IPs. Wondering if this is a
potential issue. Does zen discovery have issues with VIPs?
-T
On Saturday, August 24, 2013 12:09:03 PM UTC-7, Tinou Bao wrote:
What I've noticed is after my cluster (0.19.12) has been running for a few
days, trying to create a brand new index fails with an index already exists
exception. This is a brand new index, with a different, unique name. The
"type" is the same. So I might have:
index_a, type book mapping
index_b, type book mapping
then I try to create index_c, type book mapping, and get an index already
exists exception. Using the "head" plugin, I see the index gets created,
but it exists in a funky state. The primary seems OK, but the replica is
"unassigned".
During this time, "head" reports the cluster as red. But queries against
existing indexes seem OK.
I manually delete the bad index_c then restart the cluster. Now my code
can create index_c. A few minutes later, it can also create index_d.
Only thing that seems consistent is that the cluster
has been running for at least a few days. It's like after a few days
the cluster has some issues?
restarting the cluster solves the issue
Obviously I don't want to restart the cluster because I'm trying to
automatically create these indexes....
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.