[Tarantool-patches] [PATCH v8 1/2] applier: send transaction's first row WAL time in the applier_writer_f
Serge Petrenko
sergepetrenko at tarantool.org
Tue Jun 15 12:36:02 MSK 2021
07.06.2021 18:55, Cyrill Gorcunov пишет:
> Applier fiber sends current vclock of the node to remote relay reader,
> pointing current state of fetched WAL data so the relay will know which
> new data should be sent. The packet applier sends carries xrow_header::tm
> field as a zero but we can reuse it to provide information about first
> timestamp in a transaction we wrote to our WAL. Since old instances of
> Tarantool simply ignore this field such extension won't cause any
> problems.
>
> The timestamp will be needed to account lag of downstream replicas
> suitable for information purpose and cluster health monitoring.
>
> We update applier statistics in WAL callbacks but since both
> apply_synchro_row and apply_plain_tx are used not only in real data
> application but in final join stage as well (in this stage we're not
> writing the data yet) the apply_synchro_row is extended with replica_id
> argument which is non zero when applier is subscribed.
>
> The calculation of the downstream lag itself lag will be addressed
> in next patch because sending the timestamp and its observation
> are independent actions.
Hi! Thanks for the patch!
Looks good generally. Please, find one question below.
>
> Part-of #5447
>
> Signed-off-by: Cyrill Gorcunov <gorcunov at gmail.com>
> ---
> src/box/applier.cc | 90 +++++++++++++++++++++++++++++++++++-------
> src/box/replication.cc | 1 +
> src/box/replication.h | 5 +++
> 3 files changed, 81 insertions(+), 15 deletions(-)
>
> diff --git a/src/box/applier.cc b/src/box/applier.cc
> index 33181fdbf..38695a54f 100644
> --- a/src/box/applier.cc
> +++ b/src/box/applier.cc
> @@ -163,6 +163,9 @@ applier_writer_f(va_list ap)
> struct ev_io io;
> coio_create(&io, applier->io.fd);
>
> + /* ID is permanent while applier is alive */
> + uint32_t replica_id = applier->instance_id;
> +
> while (!fiber_is_cancelled()) {
> /*
> * Tarantool >= 1.7.7 sends periodic heartbeat
> @@ -193,6 +196,16 @@ applier_writer_f(va_list ap)
> applier->has_acks_to_send = false;
> struct xrow_header xrow;
> xrow_encode_vclock(&xrow, &replicaset.vclock);
> + /*
> + * For relay lag statistics we report last
> + * written transaction timestamp in tm field.
> + *
> + * Replica might be dead already so we have to
> + * test on each iteration.
> + */
> + struct replica *r = replica_by_id(replica_id);
> + if (likely(r != NULL))
> + xrow.tm = r->applier_txn_start_tm;
How could a replica be dead here?
AFAIR we delete a replica only when it's deleted from _cluster. Shouldn't
the applier writer be dead as well by that time?
> coio_write_xrow(&io, &xrow);
> ERROR_INJECT(ERRINJ_APPLIER_SLOW_ACK, {
> fiber_sleep(0.01);
> @@ -490,7 +503,7 @@ static uint64_t
> applier_read_tx(struct applier *applier, struct stailq *rows, double timeout);
>
> static int
> -apply_final_join_tx(struct stailq *rows);
> +apply_final_join_tx(uint32_t replica_id, struct stailq *rows);
>
> /**
> * A helper struct to link xrow objects in a list.
> @@ -535,7 +548,7 @@ applier_wait_register(struct applier *applier, uint64_t row_count)
> next)->row);
> break;
> }
> - if (apply_final_join_tx(&rows) != 0)
> + if (apply_final_join_tx(applier->instance_id, &rows) != 0)
> diag_raise();
> }
>
> @@ -751,11 +764,35 @@ applier_txn_rollback_cb(struct trigger *trigger, void *event)
> return 0;
> }
>
> +struct replica_cb_data {
> + /** Replica ID the data belongs to. */
> + uint32_t replica_id;
> + /**
> + * Timestamp of a transaction to be accounted
> + * for relay lag. Usually it is a first row in
> + * a transaction.
> + */
> + double txn_start_tm;
> +};
> +
>
--
Serge Petrenko
More information about the Tarantool-patches
mailing list