Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
T
tarantool
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package Registry
Container Registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
core
tarantool
Commits
c9a24204
Commit
c9a24204
authored
10 years ago
by
ocelot-inc
Browse files
Options
Downloads
Patches
Plain Diff
replication.xml fix small very-badly-written sentence
parent
892880b4
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/user/replication.xml
+6
-5
6 additions, 5 deletions
doc/user/replication.xml
with
6 additions
and
5 deletions
doc/user/replication.xml
+
6
−
5
View file @
c9a24204
...
...
@@ -32,17 +32,17 @@ identifier which is unique within the cluster, known as the
A replica gets all updates from the master by continuously
fetching and applying its write-ahead log (WAL).
Each record in the WAL represents a single Tarantool
command
such as INSERT or UPDATE or DELETE, and is assigned
data-change request
such as INSERT or UPDATE or DELETE, and is assigned
a monotonically growing log sequence number (LSN).
In essence, Tarantool replication is row-based:
all
data change command
s are
fully deterministic and operate
on a single
record
.
each
data change command
is
fully deterministic and operate
on a single
tuple
.
</para>
<para>
A stored program invocation
<!-- , unless requested explicitly, -->
is not written to the write-ahead log. Instead, log events
for actual
UPDATEs and DELETE
s, performed by the Lua code,
for actual
data-change request
s, performed by the Lua code,
are written to the log. This ensures that possible
non-determinism of Lua does not cause replication
to go out of sync.
...
...
@@ -85,7 +85,7 @@ identifier which is unique within the cluster, known as the
If this first
<code>
box.cfg
</code>
request occurs with
a "replication_source" clause, then the server is a replica
and its snapshot file, along with the cluster information,
is co
pied from
the master. Therefore,
is co
nstructed from the write-ahead logs of
the master. Therefore,
to start replication, specify
<olink
targetptr=
"replication_source"
/>
in a
<code>
box.cfg
</code>
request.
When a replica contacts a master for the first time, it becomes part of a cluster.
...
...
@@ -99,6 +99,7 @@ identifier which is unique within the cluster, known as the
A replica can be "re-seeded" by deleting all its files (the snapshot .snap file
and the WAL .xlog files), then starting replication again -- the replica will
then catch up with the master by retrieving all the master's tuples.
Again, this procedure works only if the master's WAL files are present.
</para>
<note><simpara>
Replication parameters are "dynamic", which allows the
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment