#506 closed defect (fixed)
replicate database failed
Reported by: | backluck | Owned by: | Richard Boulton |
---|---|---|---|
Priority: | normal | Milestone: | 1.2.4 |
Component: | Replication | Version: | 1.2.3 |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Operating System: | All |
Description
I found replicate database failed where the server and the client are in diffent marchines.
the server(Debian GNU/Linux 5.0 ):
liangjianglou@onlinegame-10-121:~/projects/yxb_index$ xapian-replicate-server -p 4444 tools/
the client(FreeBSD 5.4-RELEASE):
bash-3.1$ xapian-replicate -h 192.168.10.121 -p 4444 -m unicode -i 60 -v unicode Connecting to 192.168.10.121:4444 Getting update for unicode from unicode Update complete: 1 copies, 0 changesets, no changes to live database Connecting to 192.168.10.121:4444 Getting update for unicode from unicode Update complete: 1 copies, 0 changesets, no changes to live database Connecting to 192.168.10.121:4444 Getting update for unicode from unicode Update complete: 1 copies, 0 changesets, no changes to live database
Folder replica_1 was created, and it was deleted later. Folder replica_0 did not change.
Change History (7)
comment:1 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 14 years ago
Does "setting the XAPIAN_MAX_CHANGESETS environment variable on the indexer machine" mean running command "export XAPIAN_MAX_CHANGESETS=10" on the server machine?
I did not set XAPIAN_MAX_CHANGESETS.And it's no problem when I set the server and client on the machine.
liangjianglou@onlinegame-10-121:~$ xapian-replicate -h localhost -p 4444 -m unicode -i 60 -v unicode Connecting to localhost:4444 Getting update for unicode from unicode Update complete: 1 copies, 0 changesets, new live database Connecting to localhost:4444 Getting update for unicode from unicode Update complete: 0 copies, 0 changesets, no changes to live database Connecting to localhost:4444 Getting update for unicode from unicode Update complete: 0 copies, 0 changesets, no changes to live database Connecting to localhost:4444 Getting update for unicode from unicode Update complete: 0 copies, 0 changesets, no changes to live database
comment:3 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Sounds like my guess was correct then. I'll close this ticket, but I think the client could give a more useful explanatory message in this situation, so I've improved that in r14941.
comment:4 by , 14 years ago
Maybe my poor English made a misunderstand. When I set the server and client on the same machine, replicate database succeed. But when I set the server and client on different machines, replicate database fail.
comment:5 by , 14 years ago
Milestone: | → 1.2.4 |
---|
The problem is timing related - replicating to the same machine is much faster (because it doesn't need to go over the network) so the full copy manages to complete before database changes. When the network is involved, it takes longer and the database changes while the full copy is happening.
You really want to set XAPIAN_MAX_CHANGESETS anyway since you want to only send the changes since the last replica update. If you don't set it, a full copy of the database would have to be sent every time.
comment:6 by , 14 years ago
I do not change the database during replicating. Does the XAPIAN_MAX_CHANGESETS environment variable cause the difference of setting the server and client on the same machine and setting the server and client on different machines?
Does "setting the XAPIAN_MAX_CHANGESETS environment variable on the indexer machine" mean running command "export XAPIAN_MAX_CHANGESETS=10" on the server machine? I run the command, but it's no use.
If you replicate database succeed with setting the server and client on different machines. I think I had done some wrong.
comment:7 by , 13 years ago
Component: | Other → Replication |
---|
Are you setting the XAPIAN_MAX_CHANGESETS environment variable on the indexer machine? (see http://trac.xapian.org/browser/trunk/xapian-core/docs/replication.rst for details)
The log from the client looks to me like that's not set, so no changesets are being stored. The only thing the server can do in that situation is try and do a full copy of the database. The logs look like it's trying that, but the database on the server is being modified before the full copy finishes, so the client will have received a partially modified database, and isn't safely able to put it live. If changesets were stored, the server would send some changesets to patch the database to a consistent state, but without changesets all that can happen is a retry.
If you are setting XAPIAN_MAX_CHANGESETS, or you're not modifying the index on the server while replicating, then there's a bug here. If you're not setting XAPIAN_MAX_CHANGESETS, that'll be the problem. Please comment here either way, so I can close the ticket, or investigate the bug. Thanks.