Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#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 Richard Boulton, 9 years ago

Owner: changed from Olly Betts to Richard Boulton
Status: newassigned

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.

comment:2 by backluck, 9 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 Richard Boulton, 9 years ago

Resolution: fixed
Status: assignedclosed

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 backluck, 9 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 Olly Betts, 9 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 backluck, 9 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 Olly Betts, 9 years ago

Component: OtherReplication
Note: See TracTickets for help on using tickets.