Roman,
What is the advantage of your algorithm compared to previous one? Previous
algorithm does almost the same, but without updating two separate counters,
and looks simpler to me. Only one update is sufficient - at transaction
commit. When transaction starts we just read currently active
Vladimir,
the difference between per-transaction basis and update-counters basis
is the fact that at the first update we don't know the actual update
counter of this update - we just count deltas on enlist phase. Actual
update counter of this update will be assigned on transaction commit.
Roman,
We already track updates on per-transaction basis. The only difference is
that instead of doing a single "increment(1)" for transaction we do
"increment(X)" where X is number of updates in the given transaction.
On Mon, Dec 3, 2018 at 1:16 PM Roman Kondakov
wrote:
> Igor, Vladimir,
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 consider two
Vladimir,
Look at my example:
One active transaction (Tx1 which does opX ops) while another tx (Tx2 which
does opX' ops) is finishes with uc4:
uc1--op1op2---uc2--op1'uc3--uc4---op3X-
Node1
uc1op1uc2op2uc3--op3--uc4cp1
Igor,
Yes, I tried to draw different configurations, and it really seems to work,
despite of being very hard to proof due to non-inituitive HB edges. So let
me try to spell the algorithm once again to make sure that we are on the
same page here.
1) There are two nodes - primary (P) and backup
"If more recent WAL records will contain *ALL* updates of the transaction"
-> "More recent WAL records will contain *ALL* updates of the transaction"
On Thu, Nov 29, 2018 at 10:15 PM Vladimir Ozerov
wrote:
> Igor,
>
> Yes, I tried to draw different configurations, and it really seems to
> work,
Ivan,
different transactions may be applied in different order on backup nodes.
That's why we need an active tx set
and some sorting by their update times. The idea is to identify a point in
time which starting from we may lost some updates.
This point:
1) is the last acknowledged by all
Guys,
Another one idea. We can introduce additional update counter which is
incremented by MVCC transactions right after executing operation (like
is done for classic transactions). And we can use that counter for
searching needed WAL records. Can it did the trick?
P.S. Mentally I am trying to
Sorry, if it was stated that a SINGLE transaction updates are applied
in a same order on all replicas then I have no questions so far. I
thought about reordering updates coming from different transactions.
> I have not got why we can assume that reordering is not possible. What
have I missed?
ср,
Hi,
Regarding Vladimir's new idea.
> We assume that transaction can be represented as a set of independent
> operations, which are applied in the same order on both primary and backup
> nodes.
I have not got why we can assume that reordering is not possible. What
have I missed?
вт, 27 нояб.
Vladimir,
I think I got your point,
It should work if we do the next:
introduce two structures: active list (txs) and candidate list (updCntr ->
txn pairs)
Track active txs, mapping them to actual update counter at update time.
On each next update put update counter, associated with previous
Ivan,
1) The list is saved on each checkpoint, wholly (all transactions in active
state at checkpoint begin).
We need whole the list to get oldest transaction because after
the previous oldest tx finishes, we need to get the following one.
2) I guess there is a description of how persistent
Just thought of this a bit more. I we will look for start of long-running
transaction in WAL we may go back too far to the past only to get few
entries.
What if we consider slightly different approach? We assume that transaction
can be represented as a set of independent operations, which are
Igor,
Could you please elaborate - what is the whole set of information we 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
Igor,
Could you please clarify some points?
> 1) preserve list of active txs, sorted by the time of their first update
> (using WAL ptr of first WAL record in tx)
Is this list maintained per transaction or per checkpoint (or per
something else)? Why can't we track only oldest active
16 matches
Mail list logo
