►
From YouTube: 2020-02-25: High availability Gitaly demo
Description
Walk though of setup documentation.
Learn more: https://docs.gitlab.com/ee/administration/gitaly/praefect.html
A
C
C
C
C
C
It's
like
make
sure
that
you
have
a
server
or
like
a
computer
with
the
psql
tool
installed
and
it
was
sort
of
like
a
dead
end,
but
I
think
we
should
just
instruct
users
to
like
SSH
into
a
box
that
omnibuses
has
already
installed
psql
on,
because
then
we
don't
need
to
like
have
people
to
install
local
dependencies
as
part
of
this
process
to
create
the
user.
So
I
said
I
changes
to
read
basically
SSH
and
the
prefect
node,
so
I've
done
that.
C
C
C
All
right,
password,
okay,
the
password
is
very
securely
prefect,
SQL
password
for
anyone
watching
on
YouTube.
This
node
will
be
deleted
before
you
see
it
all
right
template
one
I
found
this
confusing
because
I
don't
know
that
template
one
is
a
magic
table
that
apparently
or
database
that
or
always
exists.
But
apparently
this
is
a
trick.
So
this
succeeds
I
think
we
should
probably
add
some
explanatory
note
like
what
is
going
on
here,
because
otherwise
it's
just
sort
of
magic
and
likewise
template
wanna.
Think
it's
a
bit
confusing.
C
Yeah,
there's
all
these
different
magic
tricks
that
I
know
it's
nice
to
learn
what
magic
is
going
on
when
you're
reading
Doc's
all
right,
we're
going
to
create
the
user
I
did
notice.
This
is
kind
of
a
different
process
to
the
Geo
Doc's,
because
they
connect
in
and
then
run
like
a
slightly
different
command
for
creating
the
user
and
then
creating
the
database
and
doing
some
older
thing.
So
I
don't
know
enough
about
strengths
and
weaknesses.
C
D
C
C
C
This
is
another
like
nitpick
I.
Don't
know
that
I,
like
the
/q,
like
copying
and
pasting
like
running
and
then
immediately
quitting
like
I,
feel
like
either.
We
should
explain
how
to
exit
or
like
ask
them
to
do
that,
because
it's
a
little
weird
to
like
start
a
process
and
then
like
execute
a
command
and
suddenly
it
exits.
I
don't
know
if
it's
still
exits
if
the
first
command,
but
it
feels
a
little
strange
to
me
anyway.
E
A
E
C
So
I
think
that
section
is
done.
Can
someone
make
a
note
that
there's
no
sort
of
like
conclusion,
summary
note
sort
of
saying,
like
you've
now
configured
the
database
to
serve
ends
prefix
next
section
to
complete
this
section?
You
will
need
configure
Postgres
server.
Yes,
we
just
did
that.
We
need
to
know
the
server
address
and
the
password
okay,
so
we're
still
on
the
prefect
node
from
the
last
step
still
is
root,
so
one
thing
I
also
did
was
break
up.
C
The
docs
word
I
went
through
last
week
when
I
did
the
recording
by
myself
it
was
just
a
huge
wall
of
config
for
gitlab
are
being.
It
was
like
copy
and
paste
this
and
update
five
locations,
and
then
you
had
to
read
all
the
comments
in
the
blocks
like
above
and
below
different
chunks
and
I
found
that
kind
of
hard
to
read
and
like
work
out.
C
What
was
going
on
so
I
I
broke
this
up
into
like
multiple
steps
which
are
like
they're
all
adding
config
to
the
gitlab
are
be,
but
it's
like
clear,
a
sort
of
explanatory
like
we're
making
this
change
to
do
this
and
we're
making
another
change.
It's
the
same
file
to
do
this
other
thing
happy
to
hear
feedback.
If
people
think
that's
a
bad
change.
A
C
B
C
Do
like
the
fact
that
in
the
docks
we
weren't
surrounding
things
that
need
to
be
replaced
with
Curly's,
and
so
everything
is
a
word
in
vim.
So
you
could
just
change
the
word,
so
you
don't
need
to
know
all
the
advanced
word
motions
if
you
using
vim
to
replace
these
placeholders
say
I,
don't
know
if
anyone
actually
thought
of
that
when
they
were
doing
it
but
I
enjoyed
it.
C
D
E
C
We
could
have
a
section
at
the
bottom
for,
like
SSL
configuration
and
link
to
that
I,
don't
know
I,
don't
need
to
change
any
of
those
settings,
configure
the
prefect
cluster
to
connect
to
each
Gili
node
in
the
cluster,
so
I
one
thing
I
did
based
on
last
time
we
spoke.
All
together
was
talking
about
this
configuration
here
and
trying
to
explain
more
of
what's
going
on
and
I
did
this
in
the
get
early
nodes
as
well
and
to
explain
what
each
thing
is
doing
and
what
needs
to.
A
B
C
C
C
Did
notice
in
the
docs
when
you
view
them
on
docstoc
gitlab,
there's
a
nice
little
copy
and
paste
thing
next
is
blocks,
but
it
means
that
whenever
you've
got
one
of
these
commands,
it
actually
requires
you're
doing
a
substitution
inside
of
it.
You
have
no
opportunity
to
do
the
substitution
because
you
paste
it
and
it
immediately
executes.
C
Right,
it
did
make
me
wonder
like
if
there
are
things
where
substitution
is
needed.
If
we
and
they're
going
to
like
actually
execute
like
they're
run
in
the
shell,
maybe
we
should
not
try
to
avoid
those
substitutions
where
possible,
to
prevent
people
like
executing
commands.
Unexpectedly,
all
right
verify
that
we
can
reach.
C
C
Like
the
one
we
just
did
here,
so
if
I
just
click
copy
and
then
I
run
here
and
then
just
go,
I'm
just
doing
command,
V
I
noticed
that
executor
I
did
not
press
the
Enter
key.
So
I
noticed
this
in
the
context
of
these
commands
up
here,
where
you
made
it
into
the
server
address,
because
I
like
copied
it
and
then
I
tried
to
paste
it
in
and
then
like
backspace
over
it
and
like
it
was
already
executed.
C
C
C
Playing
each
of
these
steps
on
each
get
early
node,
we
need
the
prefect
node
configured
done.
We
need
three
or
more
says:
we've
get
eleven
still
to
be
configured
as
giving
grades.
You're
not
run
other
services
on
these
every
goodly
server
and
assigns
the
priests
every
server
configuration
is
the
same
as
this
except
storage
names
are
exposed
to
prefect,
not
get
lab
secret,
total
perfect.
C
B
C
Yeah,
okay:
this
was
another
thing
that
I
noticed
is
that
we
set
the
get
web
shell
token
in
the
configuration,
and
then
we
manually
set
it
in
the
get
lab
application
server
and
that's
interesting
because
that
is
different
to
what
geo
dos
geo
copies
the
secrets
JSON
file
from
the
primary
to
all
the
other
nodes.
So
they
share
the
same
secrets.
C
We
should
probably
be
consistent
in
how
we
do
that,
because
it's
a
bit
weird
that
it
might
be
setting
the
secrets,
JSON
file
and
then
we're
overriding
it,
maybe
in
the
get
lab
RB
file
on
the
application
server
and
then
we're
copying
that
around,
even
though
we
could
be
using
secrets
file,
so
it's
just
done,
it
seems
like
we
should
use
the
same
approach
that
geo
does,
but
I
don't
know.
If
there's
a
specific
reason,
we
did
it.
This
I
don't
know.
D
C
D
C
B
A
D
C
C
B
C
B
D
E
C
B
A
C
C
C
C
D
C
C
B
C
Hey
that
looks
promising.
I
noticed
this
as
well.
I,
don't
think
this
is
an
issue
with
prefect
I
think
this
is
an
issue
with
me
being
lazy
and
not
setting
the
main
name
and
if
anything
is
possibly
related
to
changes
that
the
source
code
team
made
about
like
the
app
like
downloading
things
asynchronously.
So
it
hits
the
API
and
it
uses
the
configured
server
name.
For
that,
so
I
think
the
fix
is
to
actually
change
that
the
config
here.
A
C
It
did
get
created,
we
can
see
the
initial
commit,
so
just
make
sure
this
thing
comes
back
up.
C
C
No
I
think
that's
what
we
should
do
now.
Yes,
Kai,
so
the
storage
locations
is
the
sharding
mechanism.
So
it's
possible
today
to
configure
multiple
shards,
so
they
wouldn't
have
any
extra
availability
and
it
would
be
round-robin
between
any
of
the
selected
storage
locations.
So
if
you
select
both
of
them,
get
lab
will
just
choose
randomly
which
one
to
select
so
git
lab.
Comm
has
50
different
storage
locations,
one
storage,
location
per
shard
and
so
prefix
shot.
Look
just
look
like
a
normal
giddily
shard
yeah.
Let's
check
if
things
are
being
replicated.
E
C
E
E
E
A
D
E
C
D
A
D
D
D
D
A
D
B
A
D
C
C
A
D
D
C
D
C
C
D
E
B
E
E
C
C
D
E
C
C
D
C
C
B
D
C
C
C
D
D
D
A
D
A
A
D
C
C
D
B
C
So
I
think,
what's
surprising
to
me:
is
that
number
three
never
recovered
and
like
I
guess
it
was?
It
was
marked
in
some
permanently
failed
state.
So,
even
though
he
did
the
rise
that
right
never
got
triggered
like
a
force.
Update
like
I
would
have
expected
that
it
would
have
been
consistent
in
that
every
no.
D
C
A
C
C
In
in
theory,
what
we
should
be
tracking
is
like
if
a
node
becomes
inconsistent,
so
like
so
the
third
like
they're
all
consistent
right.
It
is
a
starting
state.
If,
for
some
reason,
like
number
like
three
becomes
inconsistent
like
it
should
be
that
the
next
right
would
fail,
or
we
should
detect
that
with
the
health
check
or
the
checksum,
and
then
that
one
should
be
marked
as
like
meeting
recovery,
which
is
like
forced
over
right
from
the
current,
and
because
it's
in
that
state,
it
should
be
prohibited
from
being
promoted
to
the
primary.
C
It
would
be
simply
looking
at
whole
of
node
like
up
down,
and
so
we
wouldn't
have
that
control
to
sort
of
like
have
fine-grained
repository
level
management,
and
so
we,
the
risk
of
these
kind
of
situations,
is
higher
and
where
you
just
have
like
a
whole
node
go
down
because
console
besides
it's
not
accessible
and
then
just
promote
some
node
which,
because
it's
in
a
real
world
scenario,
you
are
likely
to
have
like
some
repositories
on
every
node
which
it
can
consistent.
It's
not
like
right.
This
is
gonna,
be
like
a
mixture.
That's.
D
Right,
that's
why
that's
this?
Why
I'm
scared,
eventually
consistency,
because
reconciling
these
problems
is
much
harder
right.
You
save
you
save
complexity
on
the
replication
part,
but
then
the
the
reconciliation
part
is
actually
really
hard
and
I
would
say
almost
impossible
because
got
so
many
different
projects.
Yeah.
C
C
E
E
D
Right
and
then
we
are
dependent,
even
in
that
case
you
have
to
imagine
like
two
out
of
the
three
get
the
right,
but
one
of
them
does
not.
Then
you
immediately
have
to
say
that
one's
broken
and
then
you
know
resync
it
with
one
of
the
good
ones
right
yeah,
but
re-syncing
is
tricky
because
now
you're
like
we
have
to
know
which,
like
we
all
want
to
resync
the
entire
note,
if
we
can
help
it
right,
yeah.
C
But
maybe
we
need
to
like
at
a
repository
level,
still
have
some
sort
of
housekeeping
to
sort
of
keep
track
of
this,
and
so
there's
like
two
levels
of
housekeeping,
because
we're
always
gonna
need
like
recovery
mechanisms
for
like
when
something
doesn't
reach
quorum
and
that
that's
I
guess
kind
of
what
we've
got.
But
the
layer.
We're
missing
is
like
that
state
tracking,
where
we
sort
of
keep
hold
of
that
state
around
like
who
he's
out
of
core
right.