We have two server and have set it up as follows:
Settings:
-----------------------------------------------------
Server #1 - Profiles: A, B, C
A: Search Profile - Receiver Profile updated based on B&C
B: Small subset of our website - daily indexed, (~7,000 pages)
C: All site - weekly indexed (~270,000 pages)
Server #2 - A
A: Receiver Profile, updated based on #1: B, C
There is a cross-over cable between #1, #2 for replication (192.x.x.x, cluster members),
but are otherwise accessed normally.
Both servers are upto date as of today
-----------------------------------------------------
With the above setting, using just profiles A,B works quite well and replication is not a problem. The issues arise with Profile C and the huge number of pages that it indexes.
Baseline:
Running Profile C takes about 16 hours without replication on server #1
Problem with replication to #1A, #2A:
It took over a week to index the site via Profile C. I put it out of its misery on the 11th day. In the last couple of days it was pretty much stuck on 170,000 pages in the index and was perhaps indexing 1 or 2 pages per hour. The replication queue was also not changing.
To solve the indexing issue, I modified the settings, deselecting the "remove common feature" (via topic - "walk doesn't stop" http://thunderstone.master.com/texis/ma ... 45422b5510).
With this feature disabled, it finishes the index (of 270k pages) in about 70 hours (I figure that this increase in time from the baseline was due to part of replication occurring while indexing was going on), however the replication queue is stuck with a bit over 300k items remaining (so 150k per each server). I left it at that as I was otherwise occupied for several weeks, and when I came back to it, the replication queue hasn't changed.
I have tried this twice and am stuck on pretty much the same area. I have concluded that there is an issue with replication. Any suggestions?
Settings:
-----------------------------------------------------
Server #1 - Profiles: A, B, C
A: Search Profile - Receiver Profile updated based on B&C
B: Small subset of our website - daily indexed, (~7,000 pages)
C: All site - weekly indexed (~270,000 pages)
Server #2 - A
A: Receiver Profile, updated based on #1: B, C
There is a cross-over cable between #1, #2 for replication (192.x.x.x, cluster members),
but are otherwise accessed normally.
Both servers are upto date as of today
-----------------------------------------------------
With the above setting, using just profiles A,B works quite well and replication is not a problem. The issues arise with Profile C and the huge number of pages that it indexes.
Baseline:
Running Profile C takes about 16 hours without replication on server #1
Problem with replication to #1A, #2A:
It took over a week to index the site via Profile C. I put it out of its misery on the 11th day. In the last couple of days it was pretty much stuck on 170,000 pages in the index and was perhaps indexing 1 or 2 pages per hour. The replication queue was also not changing.
To solve the indexing issue, I modified the settings, deselecting the "remove common feature" (via topic - "walk doesn't stop" http://thunderstone.master.com/texis/ma ... 45422b5510).
With this feature disabled, it finishes the index (of 270k pages) in about 70 hours (I figure that this increase in time from the baseline was due to part of replication occurring while indexing was going on), however the replication queue is stuck with a bit over 300k items remaining (so 150k per each server). I left it at that as I was otherwise occupied for several weeks, and when I came back to it, the replication queue hasn't changed.
I have tried this twice and am stuck on pretty much the same area. I have concluded that there is an issue with replication. Any suggestions?
(14063) Stdout error to 127.0.0.1: Connection reset/closed?; exiting
SQLPrepare() failed with -1 in the function prepntexis