gt;> if we do so, we can benifit:
> >>>>
> >>>> 1. no need to treat meta table as a special way. this will simplify
> the
> >>> code
> >>>> a lot
> >>>> 2. ZK is highly available, so we don't worry the availablility of
;>>>
>>>> if we do so, we can benifit:
>>>>
>>>> 1. no need to treat meta table as a special way. this will simplify the
>>> code
>>>> a lot
>>>> 2. ZK is highly available, so we don't worry the availablili
> I used to be a fan, but I think self hosting all important meta data is the
> best approach. It makes lots of things easier, like replication, snapshots,
> etc.
+1
t; > >
> > > if we do so, we can benifit:
> > >
> > > 1. no need to treat meta table as a special way. this will simplify the
> > code
> > > a lot
> > > 2. ZK is highly available, so we don't worry the availablility of the
> >
e
> meta
> > data.
> > 3. currently if the region server where meta table is on failed, the
> whole
> > cluster may pause.
> > if we move meta table to ZK, there is no such problem.
> > 4. meta table may be a hotspot, but in ZK reading is scalable by adding
> more
> > observers.
> >
> >
> > Sincerely
>
lify the
> > code
> > > a lot
> > > 2. ZK is highly available, so we don't worry the availablility of the
> > meta
> > > data.
> > > 3. currently if the region server where meta table is on failed, the
> > whole
> > > cluster may pause.
> > > if we move meta table to ZK, there is no such problem.
> > > 4. meta table may be a hotspot, but in ZK reading is scalable by adding
> > more
> > > observers.
> > >
> > >
> > > Sincerely
> >
>
't worry the availablility of the
> meta
> > data.
> > 3. currently if the region server where meta table is on failed, the
> whole
> > cluster may pause.
> > if we move meta table to ZK, there is no such problem.
> > 4. meta table may be a hotspot, but in ZK reading is scalable by adding
> more
> > observers.
> >
> >
> > Sincerely
>
ify the
code
> a lot
> 2. ZK is highly available, so we don't worry the availablility of the meta
> data.
> 3. currently if the region server where meta table is on failed, the whole
> cluster may pause.
> if we move meta table to ZK, there is no such problem.
> 4. meta table
available, so we don't worry the availablility of the meta
data.
3. currently if the region server where meta table is on failed, the whole
cluster may pause.
if we move meta table to ZK, there is no such problem.
4. meta table may be a hotspot, but in ZK reading is scalable by adding
