diff --git a/doc/user/replication.xml b/doc/user/replication.xml
index cd54a9556c987c8bc74b729d5e57955d7d685ab5..025c103ba7783a2870ce5a95906f87dc3dce5338 100644
--- a/doc/user/replication.xml
+++ b/doc/user/replication.xml
@@ -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 commands 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 DELETEs, performed by the Lua code,
+    for actual data-change requests, 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 copied from the master. Therefore,
+    is constructed 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