►
From YouTube: GitLab Geo Preso
Description
Nick Nguyen, Engineering Manager for Geo, provides an overview of GitLab Geo
A
So,
thank
you
all
so
much
for
joining
us.
For
another
exciting
week
of
the
customer
success
skills
exchange.
This
has
been
a
hotly
requested
topic,
so
get
lab
geo.
I
think
it's
our
number
one
upvoted
topic
so
really
excited
to
dig
into
this
today,
so
we're
so
lucky
to
have
nick
and
team
with
us
to
chat
a
little
bit
more
about
it
in
depth,
so
we'll
be
starting
with
a
geo
overview
and
then
diving
into
some
more
technical
topics,
including
http
and
https
load,
balancing
failover,
so
promoting
that
secondary
node
three
was
a
backup
strategy.
A
B
B
I
believe
yeah
mike
one
of
our
staff
engineers,
is
on
the
call,
as
well
as
oh,
see,
gabriel,
just
joined
and
catalin
also
a
support
engineer
specializing
in
geos
with
us,
so
plenty
of
people
here
to
help
answer
any
questions
that
y'all
might
have
so
yeah
I'll
just
I
know
there
is
probably
a
varying
level
of
geo
familiarity
on
this
call.
So
I
wanted
to
do
an
overview.
B
Awesome
all
right,
okay,
so
yeah,
so
so
what
is
geo
geo
at
at
its
most
basic
level
is
a
way
to
provide
a
read
only
secondary
gitlab
instance
of
of
a
customer's
main
gitlab
instance.
So
we
use
the
term
geo
primary.
That
is
the
that
is
the
main
gitlab
installation
that
you
can
read
and
and
write
to
and
then
geo
provides.
The
ability
to
set
up
secondary
geo
sites
secondary
is
a
read-only
mirror
of
the
primary
gitlab
instance.
B
There
can
be
multiple
secondary
sites,
but
there
can
only
be
one
primary.
You
can
perform
get
operations
on
the
secondaries
for
increased
performance.
So
if
you
look
at
the
graphic
here,
we
our
standard
example
is
you
have
maybe
an
office
in,
say
san
francisco
and
then
a
european
office
in
the
netherlands,
and
so
you
have
two
development
teams
at
each
of
those
sites,
and
so
maybe
your
primary
get
lab
instances
in
san
francisco.
B
B
So
so
you
can.
You
can
do
some
operations
that
might
resemble
a
write
on
the
secondary,
but
those
are
proxy
to
the
secondary
to
the
primary.
So,
for
example,
get
pushes
you
can
do
a
git
push
to
the
secondary
and
then
that
will
be
proxied
to
the
primary
and
then
another
thing
to
understand
about
geo
is
that
is
that
it's
eventually
consistent,
meaning
that
there
can
be
replication
lag
between
the
primary
and
secondary.
B
It's
not
an
active,
active
setup,
so
so
they're,
not
always
in
sync
but
but
the
secondary,
so
the
secondary
can
be
a
little
behind
the
primary,
but
it
if
you
kind
of
waited
things,
would
eventually
catch
up
all
right
so
that
what
are
the
primary
use
cases
for
geo.
So
one
is
geo-replication
the
scenario
I
just
described.
Maybe
you
have
multiple
offices
and
you
want
your
developers
to
have
to
have
increased
better
performance
when
using
git
labs.
So
so
we
we.
So
we
consider.
B
We
call
that
geo
replication
and
that
can
reduce
the
time
it
takes
to
fetch
and
clone
repositories
and
increase
developer
productivity
for
distributed
teams.
The
other
major
use
case
for
geo
is
disaster
recovery,
so
for
customers
that
that
have
business
continuity
needs
and
fault
tolerance
needs
geo
can
provide
a
warm
standby
that
customers
can
fail
over
to
in
in
the
event
of
of
a
disaster.
B
B
We
utilize
postgres
streaming
replication
to
to
replicate
the
entire
database
of
the
primary
to
the
secondary
node
for
customers.
With
that
use
ldap.
We
recommend
that
there's
also
a
replica
of
that
server
on
the
secondary
site
and
then
for
data.
That's
not
stored
in
the
main
postgres
database.
Things
like
attachments,
ci,
artifacts,
lfs
objects,
as
well
as
get
repositories.
B
We
use
yeah.
We
use
jwt
based
authentication
to
to
transfer
those
from
the
primary
to
the
secondary,
and
if
we
look
here,
there's
a
geo
tracking
database
that
helps
the
secondary
know
what
needs
to
be
synced
and
in
terms
of
these,
like
files
and
repositories,
there's
a
geo
log,
cursor
process
that
runs
on
the
secondary
to
facilitate
that
syncing.
If
you
see
here,
there's
a
little
line
that
says
ftw
prior
to
someone
correct
me.
B
If
I'm
wrong
get
lab
13
3,
we
used
foreign
data
wrappers
for
cross
database,
queries
between
the
geo
tracking
database
and
and
the
main
postgres
database
as
of
get
lab
133.
That
has
been
the
need
for
foreign
data.
Wrappers
has
been
removed.
So
that's
a
was
a
really
exciting
achievement
for
the
geo
team.
We
still
need
to
update
this
architecture
diagram
but,
as
a
result,
a
lot
of.
B
B
Yet
that's
one
of
the
big
focuses
of
the
geo
team
right
now,
but
I
think
it's
important
to
understand
these
limitations
and
so
that,
when
talking
with
customers,
we
know
whether
we're
we're
replicating
everything
that
they
care
about.
So
so
there's
this
table
that
you
can
look
at
that
I've
linked
to
here
that
we
keep
updated
with
all
of
the
possible
data
types
that
someone
might
care
about
replicating
as
new
ones
are
added.
B
B
We
do
support
postgres
aj
clusters
on
geoprimaries,
but
right
now
doing
that
on
the
secondary
node
is
not
supported.
There
are
also
limitations
and
risks
when
it
comes
to
failovers
on
postgres
clusters
on
the
primary
node.
If,
if
you
fail
over,
the
geosecondary
doesn't
necessarily
have
doesn't
necessarily
know
to
to
follow
the
new
leader
right
away.
So
those
are
also
some
issues
where
we're
working
through
selective
sync
is
available
as
part
of
the
geo
solution.
So
you
can,
you
can
specify
a
group
or
a
storage
shard
to
replicate
on
the
secondary.
B
This
helps
with
the
amount
of
non-database
data
that
needs
to
be
replicated,
but
it
will
still
replicate
the
entire
postgres
database,
so
so
there's
currently
no
no
solution
for
only
replicating
parts
of
parts
of
the
main
database
and
then,
as
I
mentioned
before,
active
active,
is
not
supported.
It's
a
it's.
A
warm
standby,
that's
eventually
consistent!
So
there's
there's
going
to
be
some
replication
lag
between
the
primary
and
secondary.
B
B
Instead
of
knows
so,
and
as
we
so,
we
implemented
the
the
initial
self-service
framework
and
then
we've
been
working
on
adding
new
data
types
such
as
external,
mr
diffs,
working
on
version,
terraform
state
files,
currently
we're
working
on
replicating
snippet
repositories
and,
and
then,
after
that,
as
part
of
disaster
recovery,
complete
maturity.
We
want
to
do.
We
want
to
add
more
data
types.
We
want
to
move
some
of
the
existing
data
types
that
we
replicated
over
to
the
self-service
framework.
B
Other
complete
maturity,
things
that
we
want
to
do.
We
want
to
improve
the
failover
documentation,
make
them
more
linear,
run
book
style
instructions
we're
currently
working
on
a
read-only
maintenance
mode
which
currently,
which
isn't
available
right.
Now,
we're
also
working
on
you
being
able
to
support
high
availability
postgresql
on
geosecondaries
using
petroni,
so
postgres
12
is
going
to
be
available.
B
It
is
going
to
be
I
it
already
is
available
as
an
opt-in,
I
think
it's
going
to
be
the
required
version
in
get
lab,
14
and
and
along
with
that,
we
can
rep
manager.
Won't,
is
not
supportive
with
that.
So
petroni
is
the
preferred
solution
for
for
aj
postgres
going
forward,
and
then
the
other
big
thing
that
we're
working
on
for
complete
maturity
is.
B
B
So
that's
a
big
component
of
the
complete
maturity
work
that
we
hope
to
get
to
soon
all
right,
so
that
was
the
geo
overview.
So
now
so
I've
made
some
slides
for
each
of
these
technical
topics
that
were
listed
out
in
the
in
the
issue.
Please
feel
free
to
jump
in
with
any
questions
as
I'm
going
through
them.
B
So
one
question
that
was
asked
was:
is
it
possible
to
is
it
possible
for
geo
to
communicate
via
http,
or
does
it
have
to
be
https?
Yes,
it's
possible.
It's
generally
a
bad
idea,
because
you're
going
to
transfer
data
between
geo
nodes
unencrypted,
you
can
certainly
do
that
if
you're
just
setting
up
a
demo,
instance
or
or
something
like
that,
but
we
definitely
recommend
for
any
production
geo
deployment
that
traffic
is
encrypted
and
yeah.
B
There's
a
link
to
to
some
setup
documentation
there
on
the
slide
load,
balancing
also
came
up
and,
yes,
it
is
possible
to
have
multiple
secondary
nodes
behind
a
single
load.
Balancer,
currently
putting
a
a
primary
behind
a
geo,
node
balancer
isn't
supported.
That
would
require
secondaries
to
to
be
writable.
We
do
have
an
issue
open
for
it
and
you
can
also
provide
get
lab
users
with
a
single
location
aware
get
remote
url,
so
that
users
will
automatically
use
the
the
geo
node
nearest
to
them.
B
One
project
that
has
the
potential
to
provide
some
automation
around
failover
is
the
gitlab
orchestrator
project.
If
you,
if
you
haven't
seen
it
yet,
I
definitely
encourage
you
to
check
it
out.
It's
a
project,
that's
that
the
distribution
team
is
working
on
and
is
currently
getting
ready
for
an
alpha
release,
so
still
lots
of
development
ongoing
there
and
and
not
ready
for
production
usage.
B
B
B
B
B
So
if
something
does
go
wrong,
you
you
can,
you
can
fail
over
to
the
secondary
and
and
most
maybe
all
of
the
data
you
you
care
about,
will
be
there,
but
geo
does
not
replace
the
need
to
keep
regular
backups.
So
so,
even
if
geo
replicates
everything,
a
customer
cares
about.
Geoff
follows
the
primary
very
closely
and
so
a
potential
scenario
that
geo
would
where
geo
would
not
be
great
as
a
backup
strategy.
B
As
if
say
someone
performed
an
upgrade
on
the
primary
of
their
upgrade
of
their
gitlab
version
on
the
primary
and
a
bug
causes
tables
on
the
primary
to
be
a
race.
Well,
the
secondary
faul
can
follow
pretty
quickly
behind
the
the
primary,
and
so
you
would
also
replicate
this
change
to
to
the
secondary.
So,
in
that
case,
your
secondary
would
be
in
a
bad
state
and
you
will
have
wanted
a
regular
backup
of
your
of
your
primary
instance.
B
So
yeah
definitely
part
of
a
backup
strategy,
but
we
still,
we
still
recommend
keeping
regular
backups
of
your
of
the
primary
instance
and
then,
of
course,
yeah.
There's
an
attack
scenario
too,
where
customer
servers
are
compromised
by
a
third
party.
All
those
servers
in
the
same
network
start
encrypting
data,
this
yeah.
This
would
affect
the
primary
and
the
secondary.
So
another
situation
where
you
would
still
want
a
backup.
That's
independent
of
your
geosecondary.
B
Yeah
something
that
this
wasn't
a
topic
that
anyone
brought
up,
but
something
I
wanted
to
highlight
was
that
the
geo
team
is
happy
to
review
failover
runbooks
for
for
customers
with
complex
architectures.
So
recently,
two
two
large
customers
successfully
completed
disaster
recovery
tests
and
and
so
that
that
was
a
a
really
nice
accomplishment
and
really
great
thing
to
see
it's.
It's
not
oftentimes
we're
yeah.
B
B
B
We've
have
to
spin
up
a
single
node
geo
deployment
quickly
on
gcp
is
our
ansible
get
lab
geo
playbooks
so
definitely
recommend
that
if
you
ever
need
to
just
spin
up
a
quick
demo
instance,
the
gitlab
orchestrator
is
also
working
on
being
able
to
spin
up
different
reference.
Architectures
and
geo
will
be
a
part
of
that,
so
it's
currently
focusing
on
gcp
and
aws
support
will
follow,
and
I
think,
though
there
are
a
lot
of
so
those
are
two
ways
to
to
quickly
deploy
geo.
B
I
believe
the
performance
environment
builder
can
also
do
that
and
they're
adding
support
for
upgrading
geo.
One
direction
that
we
want
to
head
to
eventually
is
to
have
all
of
these
tools
to
set
up
geo
converge
on
on
a
single
solution
and
and
gitlab
orchestrator
is
aiming
to
be
that
solution
right
now
or
aiming
to
be
that
solution
eventually,
but
right
now
it
yeah
it
only
handles
certain
cases.
B
B
You
can
see
some
of
the
the
challenges
that
customers,
the
customers
that
we've
interviewed,
have
had
setting
up
geo
and
some
of
the
ideas
and
and
plans
for
improving
that
experience,
and
then
we
also
do
regular
upgrade
demos
we're
actually
a
little
behind
our
most
recent
demo
is
from
12
8
to
12
9,
and
we
we
record
these.
We
were
a
little
behind
because
we
discovered
some
issues
with
doing
zero.
B
Downtime
upgrades
on
on
the
geo
setup
that
we
were
using,
and
so
we
wanted
to
take
a
little
step
back
and
open
up
some
issues
to
investigate.
Why
why
that's
happening,
but
the
the
plan
is
anyways
to
to
keep
up
and
and
do
these
upgrade
demos
with
each
gitlab
version
that
comes
out
all
right
and
then
other
resources,
so
yeah
I'll,
just
first
of
all,
put
in
a
plug
for
the
geo
slack
channel
that
yeah
we're
always
happy
to
help
answer
questions
there.
B
I
think
our
engineers
and
support
team
are
are
quite
responsive
there,
and
so
that
is,
if
you
have
any
questions,
please
don't
hesitate
to
reach
out
on
slack
at
the
geo
channel.
I've
also
linked
to
the
administrator
docs,
the
development
team
handbook
page,
which,
which
also
has
has
some
more
information
about
about
how
best
to
engage
with
the
geo
team
for
for
support
and
then
our
epics
roadmap,
which,
which
is
nicely
organized
by
by
product
maturity
and
then
kind
of
drills
down
from
there.
B
C
C
One
of
the
things
that
I
benefit
a
lot
from
and
I
think
the
product
benefits
from
is
getting
feedback
from
you.
So
if
you
have
customers
or
prospects
or
any
questions,
please
ask
them
in
the
geochat.
I
think
also
if
they
are
customer
conversations
that
you
would
like
us
to
join
reach
out.
I
really
this
is
not
like
bothering
us
or
putting
extra
workload
on
us.
This
is
one
of
the
like
major
reasons
or
major
things
that
allow
us
to
build
the
product
that
folks
actually
want
to
use.
C
So
we
really
appreciate
any
feedback
and
all
the
questions.
I
try
to
answer
many
of
the
questions
async
in
the
doc,
so
I
I
hope
my
my
words
and
the
words
of
the
team.
You
know
help,
but
I
unfortunately
need
to
sign
off
but
you're
great.
I
I've
had
the
opportunity
to
work
with
many
of
you
already
and
thanks
so
much.