From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 4A8AD6EC56; Fri, 19 Mar 2021 16:50:42 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 4A8AD6EC56 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1616161842; bh=BFDo2G389bG5pF8tn7bYQVJmsnvfiVvcxTDAdn35wE8=; h=To:References:Date:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=pNKSYemaR9V0hE7hkrINtZ3nfuRS0UgIE5OTqgfwbj5t0XodlDGvP8gvRhjTacInI VcRZNS2UvC6ivqDR8Ibij/rm0b3q/MYYHaenNDa8f8yXlX/s4/mqBO+s+Bch4BXNMt xIni6bFSleqyLeJpaf+MsGJPNsLactP/Ld6of4JE= Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 774906EC56 for ; Fri, 19 Mar 2021 16:50:41 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 774906EC56 Received: by smtp33.i.mail.ru with esmtpa (envelope-from ) id 1lNFWR-0004YV-Tl; Fri, 19 Mar 2021 16:50:40 +0300 To: Cyrill Gorcunov , tml References: <20210318184138.1077807-1-gorcunov@gmail.com> <20210318184138.1077807-2-gorcunov@gmail.com> Message-ID: <1482a9db-549e-e720-7a7c-6f052ebbcc73@tarantool.org> Date: Fri, 19 Mar 2021 16:50:38 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210318184138.1077807-2-gorcunov@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD95D6E7CC48CB1F5F1DDD90A25A8FA528D0BFD61B598B81272182A05F538085040391B4531CA224B6EC967635872E7D1F8A053E305E87D0C4B10B76138EFC53BCC X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE707314F92EEE30EB3EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637575C0790A70C4B158638F802B75D45FF914D58D5BE9E6BC131B5C99E7648C95C81A23F326053F82746E456884E017E6610EBF75186359AE4A471835C12D1D9774AD6D5ED66289B5278DA827A17800CE78A0F7C24A37A3D769FA2833FD35BB23D2EF20D2F80756B5F868A13BD56FB6657A471835C12D1D977725E5C173C3A84C3BCA4DA3BE1BC1572CC7F00164DA146DA6F5DAA56C3B73B23C77107234E2CFBA567F23339F89546C55F5C1EE8F4F765FC352312137F7641E375ECD9A6C639B01BBD4B6F7A4D31EC0BC0CAF46E325F83A522CA9DD8327EE4931B544F03EFBC4D57B25CBF701D1BE873C4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F05F538519369F3743B503F486389A921A5CC5B56E945C8DA X-C1DE0DAB: 0D63561A33F958A528E5043742455A69D5C4BF4DDC90558A3FBF3ABB80A43883D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75F04B387B5D7535DE410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34A5112A9AECFE11B140CFFE589019A7F20091902EB161F1D26B6626F485D49D1FB159047030BCEE5C1D7E09C32AA3244C42613E55C48AB4348EAC24C17976FE5F250262A5EE9971B08D5DD81C2BAB7D1D X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojyKyJYJ15DtJ2X8t+khiVtA== X-Mailru-Sender: 3B9A0136629DC9125D61937A2360A446E253AB994F3C9C1F08F1877DEB679A7FB98E25DE38F3D98E424AE0EB1F3D1D21E2978F233C3FAE6EE63DB1732555E4A8EE80603BA4A5B0BC112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH 1/2] gc/xlog: delay xlog cleanup until relays are subscribed X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Serge Petrenko via Tarantool-patches Reply-To: Serge Petrenko Cc: Mons Anderson , Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 18.03.2021 21:41, Cyrill Gorcunov пишет: > In case if replica managed to be far behind the master node > (so there are a number of xlog files present after the last ... > src/box/replication.cc | 2 + > test/app-tap/init_script.result | 1 + > test/box/admin.result | 2 + > test/box/cfg.result | 4 ++ > 10 files changed, 153 insertions(+), 3 deletions(-) Hi!  Thanks for the patch! Please find 2 minor comments below. > > diff --git a/src/box/box.cc b/src/box/box.cc > index b4a1a5e07..ee017c2dc 100644 > --- a/src/box/box.cc > +++ b/src/box/box.cc > @@ -754,6 +754,15 @@ box_check_wal_mode(const char *mode_name) > return (enum wal_mode) mode; > } > > +static void > +box_check_wal_cleanup_delay(int tmo) > +{ > + if (tmo < 0 && tmo != -1) { > + tnt_raise(ClientError, ER_CFG, "wal_cleanup_delay", > + "the value must be either >= 0 or -1"); > + } > +} > + 1. AFAICS all other delay and timeout parameters are 'double'.    Let's make this one also a double. > static void > box_check_readahead(int readahead) > { > @@ -899,6 +908,7 @@ box_check_config(void) > box_check_checkpoint_count(cfg_geti("checkpoint_count")); > box_check_wal_max_size(cfg_geti64("wal_max_size")); > box_check_wal_mode(cfg_gets("wal_mode")); > + box_check_wal_cleanup_delay(cfg_geti("wal_cleanup_delay")); > if (box_check_memory_quota("memtx_memory") < 0) > diag_raise(); > box_check_memtx_min_tuple_size(cfg_geti64("memtx_min_tuple_size")); > @@ -3045,6 +3055,7 @@ box_cfg_xc(void) > bootstrap(&instance_uuid, &replicaset_uuid, > &is_bootstrap_leader); > } > + gc_delay_unref(); > fiber_gc(); > > bootstrap_journal_guard.is_active = false; ... > diff --git a/src/box/relay.cc b/src/box/relay.cc > index 41f949e8e..5d09690ad 100644 > --- a/src/box/relay.cc > +++ b/src/box/relay.cc > @@ -668,6 +668,13 @@ relay_send_is_raft_enabled(struct relay *relay, > } > } > > +static void > +relay_gc_delay_unref(struct cmsg *msg) > +{ > + (void)msg; > + gc_delay_unref(); > +} > + > /** > * A libev callback invoked when a relay client socket is ready > * for read. This currently only happens when the client closes > @@ -721,6 +728,19 @@ relay_subscribe_f(va_list ap) > */ > relay_send_heartbeat(relay); > > + /* > + * Now we can resume wal/engine gc as relay > + * is up and running. > + */ > + if (!relay->replica->anon) { > + static const struct cmsg_hop gc_delay_route[] = { > + {relay_gc_delay_unref, NULL} > + }; > + struct cmsg gc_delay_msg; > + cmsg_init(&gc_delay_msg, gc_delay_route); > + cpipe_push(&relay->tx_pipe, &gc_delay_msg); > + } > + 2. I agree with Vlad here. No need to call gc_delay_unref() from the relay thread.    We need to wait until a corresponding gc consumer is registered. This is done    in relay_subscribe(), which is in tx thread.    In fact, you may as well move the gc_delay_unref() call directly to gc_consumer_register().    This would look even better, IMO. > /* > * Run the event loop until the connection is broken > * or an error occurs. > diff --git a/src/box/replication.cc b/src/box/replication.cc > index 1fa8843e7..aefb812b3 100644 > --- a/src/box/replication.cc > +++ b/src/box/replication.cc > @@ -250,6 +250,7 @@ replica_set_id(struct replica *replica, uint32_t replica_id) > tt_uuid_str(&replica->uuid)); > } > replicaset.replica_by_id[replica_id] = replica; > + gc_delay_ref(); > ++replicaset.registered_count; > say_info("assigned id %d to replica %s", > replica->id, tt_uuid_str(&replica->uuid)); > @@ -273,6 +274,7 @@ replica_clear_id(struct replica *replica) > replicaset.replica_by_id[replica->id] = NULL; > assert(replicaset.registered_count > 0); > --replicaset.registered_count; > + gc_delay_unref(); > if (replica->id == instance_id) { > /* See replica_check_id(). */ > assert(replicaset.is_joining); > ... -- Serge Petrenko