Last modified: 2011-04-04 21:28:26 UTC
We are testing replication so that we can use the mediwiki on our internal servers. We have implemented a slightly different process that will still make the last digit of ID specific to the server to insure no duplicates. The problem is when the databaes are disconnected and one server does more revisions than the other, the latest revison on a given page by timestamp can have a lower rev_id. This causes the view Article page to show different text than the Edit Article or History page. I've located "max(rev_id)" and "ORDER BY rev_id" in the PHP code and modified them to get rev_id ordered by timestamp as required by the logic. This doesn't seem to have corrected the problem in all cases though. I'm having a bit of trouble determining which code segments the edit Article takes to determine the area that might need adjustment. The page_latest field in the page record is correct in all cases, but it appears different paths are taken to get the text from the database for display Article and Edit Article. Any suggestion on what I might need to look for or even where to look besides what I stated above would be appreciated. Unfortunately handling the auto increment as stated here (http://dev.mysql.com/doc/refman/5.0/en/replication-auto-increment.html) is not an option, and I would think it would have the same problem in the record lookup as I'm experiencing. This is a great tool and I am looking forward to using it in our distributed server environment. Thanks in advance
Solved that problem. Doing statement replication with mysql found where the code was adding a check into the where clause that limited the update to page_latest = rev_id. Of course the page_latest is different on a system that continued to have updates while replication was broken for 1 reason or another. Commented that out. My current issue is due to replication of innodb tables and/or the fact that some of the code paths assume that the rev_id is always the highest on the latest record. This isn't the case when you support distributed processing and have some outage in connectivity. Guess it's my problem trying to get code to work in a distributed environment when it wasn't designed that way. I do wish, however, that there was a little more consistency in how data was accessed. I only have a day or two left before we have to scrub this and go with a different wiki so no point in replying to this bug. I guess I'll just change to WONTFIX since there is no cancel I can find.
