Guys,
I have started a new topic to address the issue with DAT [1].
[1]
http://apache-ignite-developers.2346864.n4.nabble.com/IEP-4-Phase-2-Using-BL-A-T-for-in-memory-caches-td29942.html
On Tue, Apr 24, 2018 at 11:43 PM, Dmitriy Setrakyan
wrote:
> On Wed, Apr 25, 2018 at 4:13 AM, Vladimir Ozer
On Wed, Apr 25, 2018 at 4:13 AM, Vladimir Ozerov
wrote:
> Right, as far as I understand we are not arguing on whether BLT is needed
> or not. The main questions are how to properly deliver this feature to
> users and how to deal with co-location issues between persistent and
> non-persistent cach
Right, as far as I understand we are not arguing on whether BLT is needed
or not. The main questions are how to properly deliver this feature to
users and how to deal with co-location issues between persistent and
non-persistent caches. Looks like change policies are the way to go for the
first que
Well, this means that the concept of baseline is still needed because we
must not reassign partitions immediately (note that this is not identical
to rebalance delay!). The approach you describe is identical to baseline
change policies and I have nothing against this, their implementation was
plann
Alex,
CockroachDB is based on RAFT and is able to repair itself automatically [1]
[2]. Their approach looks reasonable to me and is pretty much similar to
MongoDB and Cassandra. In short, you distinguish between short-term and
long-term failures.
1) First, you wait for small time window in hope th
- for in-memory caches, affinity would calculate with SAT/BLAT on the first
step and because of it collocation would work between in-memory and
persistent caches;
- on the next step, if there are offline nodes, we would spread their
partitions among alive nodes. This would save us from data loss.
Igniters,
I have introduced DAT in opposition to BLAT (SAT) because they reflect how
Ignite works.
But I actually have concerns about the necessity of such separation.
DAT exists only because we don't want to lose any data in in-memory caches.
But there are alternatives. Besides BLAT auto-chang
Vladimir,
Automatic cluster membership changes may be implemented to grow the
topology, but auto-shrinking topology is usually not possible because a
process cannot distinguish between a node shutdown and network
partitioning. If we want to deal with split-brain scenarios as a grown-up
system, we
Ivan,
This reasoning sounds questionable to me. First, separate logic for in
memory and persistent regions means that we loose collocation between
persistent and non persistent caches. Second, “data is still on disk”
assumption might be not valid if node has left due to disk crash, or when
data is
Stan,
I believe it was discussed at the design proposal thread:
http://apache-ignite-developers.2346864.n4.nabble.com/Cluster-auto-activation-design-proposal-td20295.html
The short answer: backup factor decreases if node leaves. In
non-persistent mode we have to rebalance data ASAP - otherwis
+ for Vladimir's point - adding more complexity may (and likely will) be
even more misleading.
Can we take a step back and discuss why do we need to have different
behavior for persistent and in-memory caches? Can we make in-memory caches
honor baseline instead of special-casing them?
Thanks,
Sta
Ed,
Agreed. Can we see proposed API changes?
On Tue, Apr 24, 2018 at 6:39 PM, Eduard Shangareev <
eduard.shangar...@gmail.com> wrote:
> Vladimir,
>
> It will be fixed, But it is not user-list.
>
> We (developers) should decide ourselves how to go ahead with these
> concepts.
>
> And I think that
Vladimir,
It will be fixed, But it is not user-list.
We (developers) should decide ourselves how to go ahead with these concepts.
And I think that our old approach to describe BLAT is sophisticated and not
clear (maybe, even error-prone).
On Tue, Apr 24, 2018 at 6:28 PM, Vladimir Ozerov
wrote:
Guys,
As a user I definitely do not want to think about BLATs, SATs, DATs,
whatsoever. I want to query data, iterate over data, send compute tasks to
data. If certain node is outside of BLAT and do not have data, then this is
not affinity node. Can we just fix affinity logic to take in count BLAT
Eduard,
Can you please summarize code changes that you are proposing?
I agree that BLT is a bit misleading term and DAT/SAT make more sense.
However, establishing a consensus on v2.4 Baseline Topology terminology
took a long time and seems like you are going to cause a bit more
perturbations.
Hi, Igniters,
I want to raise a topic about our affinity node definition.
After adding baseline (affinity) topology (BL(A)T) things start being
complicated.
Plenty of bugs appears:
IGNITE-8173
ignite.getOrCreateCache(cacheConfig).iterator() method works incorrect for
replicated cache in case if
16 matches
Mail list logo
