Mailing-List: contact user-help@kudu.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@kudu.apache.org
MIME-Version: 1.0
In-Reply-To: <CADY20s4fWHho9i1-yQaXaQdDx069CbsosYC9hKb5eL5iQ8dcVw@mail.gmail.com>
References: <CAKPdV5jZ2gP1HuvQ65xraR0nTD2jHBM5han+gruGLV3P10p1LA@mail.gmail.com>
 <002a01d34e0a$9cdcec80$d696c580$@corp.netease.com> <CAKPdV5j_Ay68S0+bBQ1RAs7Q9FUfK4J_mEjJEq8cHqUUyO3PfA@mail.gmail.com>
 <003501d34e43$b8e81830$2ab84890$@corp.netease.com> <CADY20s4fWHho9i1-yQaXaQdDx069CbsosYC9hKb5eL5iQ8dcVw@mail.gmail.com>
From: =?UTF-8?B?6riw7KSA?= <0ctopus13prime@gmail.com>
Date: Fri, 27 Oct 2017 10:24:57 +0900
Message-ID: <CAKPdV5j_jQHD2hx=Sn_Gs5mn4AJfDthy8xw86M_GcdRTSX3YKg@mail.gmail.com>
Subject: =?UTF-8?B?UmU6IOetlOWkjTog562U5aSNOiBIb3cga3VkdSBzeW5jaHJvbml6ZSByZWFsLXRpbWUgcg==?=
	=?UTF-8?B?ZWNvcmRzPw==?=
To: user@kudu.apache.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 27 Oct 2017 01:25:24 -0000

@Todd Lipcon

I really appreciate your kind explanation!

Now i clearly understood it.

Have a nice day!


2017-10-27 4:09 GMT+09:00 Todd Lipcon <todd@cloudera.com>:
> What Helifu said is correct that writes are funneled through the leader.
>
> Reads can either be through the leader (which can perform immediately wit=
h
> full consistency) or at a follower. On a follower, the client can choose
> between the following:
>
> a) low consistency: read whatever the follower happens to have. Currently
> this mode is called READ_LATEST in the source but it should probably be
> called READ_ANYTHING or READ_INCONSISTENT. It reads "the latest thing tha=
t
> this replica has".
> b) snapshot consistency at current time: this may cause the follower to w=
ait
> until it has heard from the leader and knows that it is up-to-date as of =
the
> time that the scan started. This gives the same guarantee as reading from
> the leader but can add some latency
> c) snapshot consistency in the past: given a timestamp, the follower can
> know whether it is up-to-date as of that timestamp. If so, it can do a
> consistent read immediately. Otherwise, it will have to wait, as above.
>
> You can learn more about this in the recent blog post authored by David
> Alves at: https://kudu.apache.org/2017/09/18/kudu-consistency-pt1.html
> Also please check out the docs at:
> https://kudu.apache.org/docs/transaction_semantics.html
>
>
> Hope that helps
> -Todd
>
> On Thu, Oct 26, 2017 at 3:18 AM, helifu <hzhelifu@corp.netease.com> wrote=
:
>>
>> Sorry for my mistake.
>> The copy replica could be read by clients with below API in client.h:
>>
>>         Status SetSelection(KuduClient::ReplicaSelection selection)
>>         WARN_UNUSED_RESULT;
>>
>>         enum ReplicaSelection {
>>         LEADER_ONLY,      ///< Select the LEADER replica.
>>
>>             CLOSEST_REPLICA,  ///< Select the closest replica to the
>> client,
>>                           ///< or a random one if all replicas are
>> equidistant.
>>
>>             FIRST_REPLICA     ///< Select the first replica in the list.
>>         };
>>
>>
>> =E4=BD=95=E6=9D=8E=E5=A4=AB
>> 2017-04-10 16:06:24
>>
>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
>> =E5=8F=91=E4=BB=B6=E4=BA=BA: user-return-1102-hzhelifu=3Dcorp.netease.co=
m@kudu.apache.org
>> [mailto:user-return-1102-hzhelifu=3Dcorp.netease.com@kudu.apache.org] =
=E4=BB=A3=E8=A1=A8 ??
>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B410=E6=9C=8826=E6=97=
=A5 13:50
>> =E6=94=B6=E4=BB=B6=E4=BA=BA: user@kudu.apache.org
>> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: How kudu synchronize real-ti=
me records?
>>
>> Thanks for replying me.
>>
>> It helps a lot.
>>
>> 2017-10-26 12:29 GMT+09:00 helifu <hzhelifu@corp.netease.com>:
>> > Hi,
>> >
>> > Now the read/write operations are limited to the master replica(record=
1
>> > on node1), and the copy replica(record1 on node2/node3) can't be read/=
write
>> > by clients directly.
>> >
>> >
>> > =E4=BD=95=E6=9D=8E=E5=A4=AB
>> > 2017-04-10 11:24:24
>> >
>> > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
>> > =E5=8F=91=E4=BB=B6=E4=BA=BA: user-return-1100-hzhelifu=3Dcorp.netease.=
com@kudu.apache.org
>> > [mailto:user-return-1100-hzhelifu=3Dcorp.netease.com@kudu.apache.org] =
=E4=BB=A3=E8=A1=A8 ??
>> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B410=E6=9C=8826=E6=97=
=A5 10:43
>> > =E6=94=B6=E4=BB=B6=E4=BA=BA: user@kudu.apache.org
>> > =E4=B8=BB=E9=A2=98: How kudu synchronize real-time records?
>> >
>> > Hi!
>> >
>> > I read from documents saying 'once kudu receives records from client i=
t
>> > write those records into WAL (also does replica)'
>> >
>> > And i wonder it can be different time when load those records from WAL
>> > in each node.
>> > So let's say node1 load record1 from WAL at t1, node2 t2, node3 t3 (t1=
 <
>> > t2 < t3) then reading client attached node1 can see record but other r=
eading
>> > clients attached not node1(node2, node3) have possibilities missing re=
cord1.
>> >
>> > I think that does not happens in kudu, and i wonder how kudu synchroni=
ze
>> > real time data.
>> >
>> > Thanks!
>> >
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera