" :)
>> In any case, I think we're on the same page.
>>
>>> On 11 May 2021, at 13:18, Andrey Gura wrote:
>>>
>>> Stan
>>>
>>>> If archive size is less than min or more than max then the system
>>>> functi
Created the first task by this discussion IGNITE-14923.
13.05.2021, 18:37, "Stanislav Lukyanov" :
> What I mean by degradation when archive size < min is that, for example,
> historical rebalance is available for a smaller timespan than expected by the
> system design.
&g
What I mean by degradation when archive size < min is that, for example,
historical rebalance is available for a smaller timespan than expected by the
system design.
It may not be an issue of course, especially for a new cluster. If
"degradation" is the wrong word we can call i
Stan
> If archive size is less than min or more than max then the system
> functionality can degrade (e.g. historical rebalance may not work as
> expected).
Why does the condition "archive size is less than min" lead to system
degradation? Actually, the described case is a n
e=2GB.
Say, under normal load on stable topology 2 hours of WAL use 1 GB of space.
Now, say we're doing historical rebalance and reserve the WAL archive.
The WAL archive starts growing and soon it occupies 2 GB.
Now what?
We're supposed to give up WAL reservations and start agressively r
to name the property geMintWalArchiveSize. I think that this is
>> exactly what it is - the minimal size of the archive that we want to have.
>> The archive size at all times should be between min and max.
>> If archive size is less than min or more than max then the system
>
WalArchiveSize. I think that this is
> exactly what it is - the minimal size of the archive that we want to have.
> The archive size at all times should be between min and max.
> If archive size is less than min or more than max then the system
> functionality can degrade (e.g. histori
grade (e.g. historical rebalance may not work as expected).
I think these rules are intuitively understood from the "min" and "max" names.
Ilya's suggestion about throttling is great although I'd do this in a different
ticket.
Thanks,
Stan
> On 5 May 2021, at 19:25,
>
> >> Hello everybody!
> >>
> >> At the moment, if there are partitions for the rebalance for which the
> >> historical rebalance will be used, then we reserve segments in the WAL
> >> archive (we do not allow cleaning the WAL archive) until the
ing?
>
> So we will be throttling for both checkpoint page buffer and WAL limit.
>
> Regards,
> --
> Ilya Kasnacheev
>
> вт, 4 мая 2021 г. в 11:29, ткаленко кирилл :
>
>> Hello everybody!
>>
>> At the moment, if there are partitions for the rebalance f
if there are partitions for the rebalance for which the
> historical rebalance will be used, then we reserve segments in the WAL
> archive (we do not allow cleaning the WAL archive) until the rebalance for
> all cache groups is over.
>
> If a cluster is under load during the rebalan
Hello everybody!
At the moment, if there are partitions for the rebalance for which the
historical rebalance will be used, then we reserve segments in the WAL archive
(we do not allow cleaning the WAL archive) until the rebalance for all cache
groups is over.
If a cluster is under load during
Dmitry Lazurkin created IGNITE-14524:
Summary: Historical rebalance doesn't work if cache has configured
rebalanceDelay
Key: IGNITE-14524
URL: https://issues.apache.org/jira/browse/IGNITE-
Vladislav Pyatkov created IGNITE-14138:
--
Summary: Historical rebalance kills cluster
Key: IGNITE-14138
URL: https://issues.apache.org/jira/browse/IGNITE-14138
Project: Ignite
Issue Type
so
> > 1) Exclude partitions by threshold (IGNITE_PDS_WAL_REBALANCE_THRESHOLD -
> > reduce it to 500)
> > 2) Select only that partition for historical rebalance where difference
> > between counters less that partition size.
>
> Agreed, let's go this way.
>
>
> I think we can modify the heuristic so
> 1) Exclude partitions by threshold (IGNITE_PDS_WAL_REBALANCE_THRESHOLD -
> reduce it to 500)
> 2) Select only that partition for historical rebalance where difference
> between counters less that partition size.
Agreed, let's go
I completely forget about another promise to favor of using historical
rebalance where it is possible. When cluster decided to use a full balance,
demander nodes should clear not empty partitions.
This can to consume a long time, in some cases that may be compared with a
time of rebalance.
It also
e for
generic case, this should be fixed in bound of protocol.
I think we can modify the heuristic so
1) Exclude partitions by threshold (IGNITE_PDS_WAL_REBALANCE_THRESHOLD -
reduce it to 500)
2) Select only that partition for historical rebalance where difference
between counters less that part
itely makes the situation
better, but due to possible corner cases we should keep the fallback lever
to restrict or limit historical rebalance as before. Probably, it would be
handy to keep IGNITE_PDS_WAL_REBALANCE_THRESHOLD property with a low
default value (1000, 500 or even 0) and apply your heuristic
Hi guys,
I want to implement a more honest heuristic for historical rebalance.
Before, a cluster makes a choice between the historical rebalance or not it
only from a partition size. This threshold more known by a name of property
IGNITE_PDS_WAL_REBALANCE_THRESHOLD.
It might prevent a historical
Vladislav Pyatkov created IGNITE-13254:
--
Summary: Historical rebalance iterator may skip checkpoint if it
not contains updates
Key: IGNITE-13254
URL: https://issues.apache.org/jira/browse/IGNITE-13254
Vladislav Pyatkov created IGNITE-13253:
--
Summary: Advanced heuristics for historical rebalance
Key: IGNITE-13253
URL: https://issues.apache.org/jira/browse/IGNITE-13253
Project: Ignite
Vladislav Pyatkov created IGNITE-13168:
--
Summary: Retrigger historical rebalance if it was cancelled in
case WAL history is still available
Key: IGNITE-13168
URL: https://issues.apache.org/jira/browse/IGNITE
Vladislav Pyatkov created IGNITE-12935:
--
Summary: Disadvantages in log of historical rebalance
Key: IGNITE-12935
URL: https://issues.apache.org/jira/browse/IGNITE-12935
Project: Ignite
Maxim Muzafarov created IGNITE-12495:
Summary: Make historical rebalance wokring per-partition level
Key: IGNITE-12495
URL: https://issues.apache.org/jira/browse/IGNITE-12495
Project: Ignite
Ivan Rakov created IGNITE-12429:
---
Summary: Rework bytes-based WAL archive size management logic to
make historical rebalance more predictable
Key: IGNITE-12429
URL: https://issues.apache.org/jira/browse/IGNITE
Anton Vinogradov created IGNITE-12117:
-
Summary: Historical rebalance should not be processed in striped
way
Key: IGNITE-12117
URL: https://issues.apache.org/jira/browse/IGNITE-12117
Project
Alexei Scherbakov created IGNITE-11607:
--
Summary: Historical rebalance is not possible from partition which
was recently rebalanced itself
Key: IGNITE-11607
URL: https://issues.apache.org/jira/browse/IGNITE
t;> perhaps, we are focused too much on update counters. This feature was
> >> designed for the continuous queries and it may not be suited well for
> >> the historical rebalance. What if we would track updates on
> >> per-transaction basis instead of per-update basis? Let&
n Kondakov
wrote:
Igor, Vladimir, Ivan,
perhaps, we are focused too much on update counters. This feature was
designed for the continuous queries and it may not be suited well for
the historical rebalance. What if we would track updates on
per-transaction basis instead of per-update basis? Let
t; Igor, Vladimir, Ivan,
>
> perhaps, we are focused too much on update counters. This feature was
> designed for the continuous queries and it may not be suited well for
> the historical rebalance. What if we would track updates on
> per-transaction basis instead of per-update bas
Igor, Vladimir, Ivan,
perhaps, we are focused too much on update counters. This feature was
designed for the continuous queries and it may not be suited well for
the historical rebalance. What if we would track updates on
per-transaction basis instead of per-update basis? Let's conside
consistency is possible then we might be able to fix historical
rebalance for other cache modes as well. Main point here is that
having only one common mechanism is much better. Of course if it is
feasible.
пт, 30 нояб. 2018 г. в 02:02, Seliverstov Igor :
>
> Vladimir,
>
> Look at my
e: cp1 [current=uc1, backpointer=uc1]
> >
> > Example 2: one active transaction:
> > ---
> > | |
> > uc1op1uc2op2op3uc3cp1
> >
2: one active transaction:
---
| |
uc1op1uc2op2op3uc3cp1
^ |
--
state: tx1 -> op3 -> uc2
cp1 [current=uc3, backpointer=uc2]
7) Historical rebalance:
7.1) Demander finds latest checkpoint, get it's
Example 1: no active transactions.
> uc1cp1
> ^ |
>
>
> state: cp1 [current=uc1, backpointer=uc1]
>
> Example 2: one active transaction:
> ---
> | |
> uc1op1----uc2op2op3uc3cp1
>^ |
>
; > > > >
> > > > >
> > > > > вт, 27 нояб. 2018 г. в 11:19, Vladimir Ozerov <
> voze...@gridgain.com>:
> > > > >
> > > > >> Igor,
> > > > >>
> > > > >> Could you please elabor
> >> are
> > > >> going to save at checkpoint time? From what I understand this should
> > > >> be:
> > > >> 1) List of active transactions with WAL pointers of their first writes
> > > >> 2) List of prepared transactions with their up
are
> > >> going to save at checkpoint time? From what I understand this should be:
> > >> 1) List of active transactions with WAL pointers of their first writes
> > >> 2) List of prepared transactions with their update counters
> > >> 3) Partition counte
t; before which there are no prepared transactions.
> >>
> >> And the we send to supplier node a message: "Give me all updates starting
> >> from that LWM plus data for that transactions which were active when I
> >> failed".
> >>
> >>
repared transactions.
>>
>> And the we send to supplier node a message: "Give me all updates starting
>> from that LWM plus data for that transactions which were active when I
>> failed".
>>
>> Am I right?
>>
>> On Fri, Nov 23, 2018 at 1
message: "Give me all updates starting
> from that LWM plus data for that transactions which were active when I
> failed".
>
> Am I right?
>
> On Fri, Nov 23, 2018 at 11:22 AM Seliverstov Igor
> wrote:
>
> > Hi Igniters,
> >
> > Currently I’m wo
ll updates starting
> from that LWM plus data for that transactions which were active when I
> failed".
>
> Am I right?
>
> On Fri, Nov 23, 2018 at 11:22 AM Seliverstov Igor
> wrote:
>
>> Hi Igniters,
>>
>> Currently I’m working on possible approaches how
v 23, 2018 at 11:22 AM Seliverstov Igor
wrote:
> Hi Igniters,
>
> Currently I’m working on possible approaches how to implement historical
> rebalance (delta rebalance using WAL iterator) over MVCC caches.
>
> The main difficulty is that MVCC writes changes on tx active phase whil
node to which we are
applying WAL records to? I mean the state before applying WAL records.
Do we apply all records simply one by one or filter out some of them?
пт, 23 нояб. 2018 г. в 11:22, Seliverstov Igor :
>
> Hi Igniters,
>
> Currently I’m working on possible approaches how to i
Hi Igniters,
Currently I’m working on possible approaches how to implement historical
rebalance (delta rebalance using WAL iterator) over MVCC caches.
The main difficulty is that MVCC writes changes on tx active phase while
partition update version, aka update counter, is being applied on tx
Alexei Scherbakov created IGNITE-10117:
--
Summary: Node is mistakenly excluded from history suppliers
preventing historical rebalance.
Key: IGNITE-10117
URL: https://issues.apache.org/jira/browse/IGNITE-10117
ARomantsov created IGNITE-9827:
--
Summary: Assertion error due historical rebalance
Key: IGNITE-9827
URL: https://issues.apache.org/jira/browse/IGNITE-9827
Project: Ignite
Issue Type: Bug
Ivan Rakov created IGNITE-8946:
--
Summary: AssertionError can occur during reservation of WAL
history for historical rebalance
Key: IGNITE-8946
URL: https://issues.apache.org/jira/browse/IGNITE-8946
Github user Jokser closed the pull request at:
https://github.com/apache/ignite/pull/3791
---
Pavel Kovalenko created IGNITE-8390:
---
Summary: WAL historical rebalance is not able to process
cache.remove() updates
Key: IGNITE-8390
URL: https://issues.apache.org/jira/browse/IGNITE-8390
Project
GitHub user Jokser opened a pull request:
https://github.com/apache/ignite/pull/3791
IGNITE-8116 Historical rebalance fixes
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8116-8122
Alternatively
52 matches
Mail list logo
