Hi blackfield,
I can't reproduce the issue with changing number of backups when cache was
re-created.
On Fri, Oct 27, 2017 at 8:45 PM, blackfield
wrote:
> @Andrew Mashenkov, I notice that you opened IGNITE-6781.
> However, I actually destroyed the original cache with backup == 1, recreate
> a
@Andrew Mashenkov, I notice that you opened IGNITE-6781.
However, I actually destroyed the original cache with backup == 1, recreate
a new cache with backup ==2 and repopulate the table.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi,
We know one serious source of slowdown when backups are enabled. See [1]
and [2]. It will be fixed in 2.4.
Vladimir.
[1] https://issues.apache.org/jira/browse/IGNITE-6624
[2] https://issues.apache.org/jira/browse/IGNITE-6626
On Thu, Oct 19, 2017 at 9:29 PM, blackfield
wrote:
> Here, I am
Hi,
You wrote you use persistence=enabled.
Looks like you try to start cache with changed (backup=2) configuration
without recreating the cache,
grid restore cache from store with its config and doesn't apply a new one.
Looks weird that neither new number of backups wasn't applied nor error
occur
Here, I am trying to ascertain that I set backup == 2 properly as I mentioned
above that I do not see query performance difference between backup ==1 and
backup == 2.
I want to make sure that I configure my cache properly.
When I set the backup==2 (to have three copies), I notice the following v
Can you elaborate more on why if there is a scan, Ignite will have to scan
the backup as well?
Also, it appears adding additional number of backup (backup ==2 instead of
1) does not incur additional performance cost?
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Backup copies are stored along with primary copies in the same storage and
indexed by same indexes. As a matter of fact, any backup copy can become a
primary copy at any moment of time due to topology change. Therefore, if
there a scan, the amount of data you have to go through doubles when you add
The table is created programmatically, two properties (zone and userId) were
marked(annotated) with index = true.
When you say, if the index are applied properly to the query, do you mean
whether I provide the index hint to the query or else? If the former, the
answer is no.
The performance issu
Hi,
Do you have indexes configured and (if yes) are they applied properly to the
query? Did you check the execution plan?
It sounds like your query have to scan the whole cache which gets slower
with backups. Can you provide your full cache configuration and data model?
-Val
--
Sent from: htt
