From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id F305E46970E for ; Fri, 27 Dec 2019 16:31:30 +0300 (MSK) Received: by mail-lf1-f66.google.com with SMTP id l18so12486760lfc.1 for ; Fri, 27 Dec 2019 05:31:30 -0800 (PST) Date: Fri, 27 Dec 2019 16:31:27 +0300 From: Konstantin Osipov Message-ID: <20191227133127.GA29577@atlas> References: <20191226044338.GB1337@atlas> <20191226050259.GD1337@atlas> <1577451369.509620710@f196.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1577451369.509620710@f196.i.mail.ru> Subject: Re: [Tarantool-patches] [PATCH 4/5] vclock: ignore 0th component in comparisons. List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Petrenko Cc: Vladislav Shpilevoy , tarantool-patches * Sergey Petrenko [19/12/27 15:56]: > >Четверг, 26 декабря 2019, 8:03 +03:00 от Konstantin Osipov : > I couldn't find any code where id 0 is reserved. It is used in initial join. > What do you mean by "the changes of expelled replicas"? Check the comment in replica_clear_id. Right now when you delete replica from _cluster, you keep its slot in vclock. The goal is to reuse it. > However, it's true that vclock comparisons are used in creating snapshots > and finding the latest xlog on recovery. > So an anonymous replica won't create new snapshots if the only new changes > are the one made on the anonymous replica. Some problems with recovery may > also exist. I don't know whether it's severe enough, but looks not so good. > Thanks for pointing this out! > > > > > > > A much safer bet would be to use a new special id number, like > > UINT64_MAX, and not change meaning of an existing id. > > This won't help IMO. We still have cases where this vclock component > should be ignored (replication) and cases where it should be taken into > account (checkpoint/xlog clock). > What about this change? I pushed it to the branch. > Also there's no need to fix vclock tests anymore. It is also a hack. It's best if all of the complexity of an anonymous replica resides on it and the master doesn't deal with it in any way. Refusing the connection from master with a proper error message seems to be simple & reliable way to do it without mangling vclock logic. The anonymous replica would still have to find a legal slot in vclock for its own changes, but this would be a standard slot. -- Konstantin Osipov, Moscow, Russia