From dev-return-45845-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Thu Apr 25 15:24:27 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 27A9A180638 for ; Thu, 25 Apr 2019 17:24:27 +0200 (CEST) Received: (qmail 10453 invoked by uid 500); 25 Apr 2019 15:24:26 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 10375 invoked by uid 99); 25 Apr 2019 15:24:26 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Apr 2019 15:24:26 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 908DEC24C2 for ; Thu, 25 Apr 2019 15:24:25 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.836 X-Spam-Level: * X-Spam-Status: No, score=1.836 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.164, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gridgain-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id E98a8jJjTb1u for ; Thu, 25 Apr 2019 15:24:23 +0000 (UTC) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 0C5775F2AC for ; Thu, 25 Apr 2019 15:24:23 +0000 (UTC) Received: by mail-it1-f177.google.com with SMTP id x132so750387itf.2 for ; Thu, 25 Apr 2019 08:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gridgain-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=UKkCCnfQytGXOd56qcWyO5KIX3/BPC8RnkTbiIvpNaU=; b=MJ1gN+vPwrmyDDL8tj+na2Dmk17KM5J01Un2fb+cMGoCl9aBVde+OUhvR6K7oJb+IW 9lJ5nO4lRWSeuWJX13HCGV1W+3rnVlDJB73tXFK4ZnZn2iDmDrIPjyO6D8ToM/OwTOrf 1vSxIJ9K2dbeyqEk8rMOrj4mOsKTrS57BAw/g3y/dEQ1iA6zZj+cO1zmhdkn4VtRic8P PkDAL/Infv+g6X3dR03Pd0wylYXUWq3VyStWKSXBuEKUFoxI6swUWsr24utY6A+LJ0VW ULf1Yj0WCum1mTFx2N1BgjwdYSBnewlryNWg526ZIX9vyr8DpOSK6LmVzq24bu+oPzsQ u5CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=UKkCCnfQytGXOd56qcWyO5KIX3/BPC8RnkTbiIvpNaU=; b=cq0Tu42uL0AaHiyeeK2tuqJ1ub/odqllCTx0fobfPibdV4EvP7+bwPbv1Fte4luY1z a/N6CEAx8HtIK1hbjIc5OPpC6qY+UVuHGnIrVLsJgFQnOUUGzgM8FfszqrLBYTi97dqG Q+BRrFZoeaGyCudTa9/t/TTM9AM1J9bCM2ClN10Zpnrc4Jp5mzeOQZZkZxXN2mL+bgTe ZkzUV8GE+91cDZOV8FGl2nZAOgjKy0TNqWYjXCUxVjhcBx41Hnzw01mO4G5TZOI1QfuQ 1wtaa7Nti2dW68J32P86FzjfqpRQRnq/7Zm8boBYI6JrbcosC301vWsYh6dzU+dxS2t/ HgsA== X-Gm-Message-State: APjAAAWdMw4Q3V+DhZ0T9valaEjksQ7uXY2hDxVXJtPQBPwNybLM01Lr OlxEImdROeE33c6AtGMr55KqJY7A3hjikT5xs2lkn08rqJ4= X-Google-Smtp-Source: APXvYqxAN0j0wzS4IlxxilFINJc02T7AbFFVfFeADVnRZAYqBF3BAhNeyE37vLrJt9D70nQjeKekztHhevisoSypFSg= X-Received: by 2002:a24:57cf:: with SMTP id u198mr4673385ita.162.1556205861370; Thu, 25 Apr 2019 08:24:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sergey Kozlov Date: Thu, 25 Apr 2019 18:24:10 +0300 Message-ID: Subject: Re: AI 3.0: writeSynchronizationMode re-thinking To: dev@ignite.apache.org Content-Type: multipart/alternative; boundary="0000000000009097d005875c6925" --0000000000009097d005875c6925 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ilya See comments inline. On Thu, Apr 25, 2019 at 5:11 PM Ilya Kasnacheev wrote: > Hello! > > When you have 2 backups and N =3D 1, how will conflicts be resolved? > > Imagine that you had N =3D 1, and primary node failed immediately after > operation. Now you have one backup that was updated synchronously and one > which did not. Will they stay unsynced, or is there any mechanism of > re-syncing? > Same way as Ignite processes the failures for PRIMARY_SYNC. > > Why would one want to "update for 1 primary and 1 backup synchronously, > update the rest of backup partitions asynchronously"? What's the use case= ? > The case to have more backups but do not pay the performance penalty for that :) For the distributed systems one backup looks like risky. But more backups directly impacts to performance. Other point is to split the strict consistent apps like bank apps and the other apps like fraud detection, analytics, reports and so on. In that case you can configure partitions distribution by a custom affinity and have following: - first set of nodes for critical (from consistency point) operations - second set of nodes have async backup partitions only for other operations (reports, analytics) > > Regards, > -- > Ilya Kasnacheev > > > =D1=87=D1=82, 25 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 16:55, Sergey Ko= zlov : > > > Igniters > > > > I'm working with the wide range of cache configurations and found (from > my > > standpoint) the interesting point for the discussion: > > > > Now we have following *writeSynchronizationMode *options: > > > > 1. *FULL_ASYNC* > > - primary partition updated asynchronously > > - backup partitions updated asynchronously > > 2. *PRIMARY_SYNC* > > - primary partition updated synchronously > > - backup partitions updated asynchronously > > 3. *FULL_SYNC* > > - primary partition updated synchronously > > - backup partitions updated synchronously > > > > The approach above is covering everything if you've 0 or 1 backup. > > But for 2 or more backups we can't reach the following case (something > > between *PRIMARY_SYNC *and *FULL_SYNC*): > > - update for 1 primary and 1 backup synchronously > > - update the rest of backup partitions asynchronously > > > > The idea is to join all current modes into single one and replace > > *writeSynchronizationMode > > *by the new option *syncPartitions=3DN* (not best name just for referri= ng) > > covers the approach: > > > > - N =3D 0 means *FULL_ASYNC* > > - N =3D (backups+1) means *FULL_SYNC* > > - 0 < N < (backups+1) means either *PRIMARY_SYNC *(N=3D1) or new mod= e > > described above > > > > IMO it will allow to make more flexible and consistent configurations > > > > -- > > Sergey Kozlov > > GridGain Systems > > www.gridgain.com > > > --=20 Sergey Kozlov GridGain Systems www.gridgain.com --0000000000009097d005875c6925--