We're experimenting with our Linux servers. We have a texis database on a SAN volume, mounted with read-write access from Linux box #1. Linux #2 sees the same volume, but mounted in a read-only fashion.
Searches from Linux #2 appear to be working, though of course I assume updates and inserts would not. However, is it possible that certain types of select queries will also not work? Perhaps certain ones require the use of lock or temporary semaphore files?
We're using a version of texis from October 2003, so we're fairly current, if it makes any difference. Just looking for reccomendations at this point, general thoughts. The main idea we're kicking around is to have one server handle loading new data and such, while the others would run queries against the tables throughout in a read-only fashion.
Locking will not work as semaphores are on a per server basis. That means the search could happen while an update is partially complete, with undefined results (error, or just wrong answer). If the file looks invalid it will try and fix the file, although in read-only mode that should fail, and the query might error out at that point.
Temp files should be created on the local server, so there should be a select query that would always fail.
Could I ask then, if it's possible to do what we're trying? That is, have a read-write copy of a texis database on one server, with read-only access from another, using a shared drive between the machines? Sounds like it'd be tough, but maybe there's another way.
Not with 100% reliability from the search side, as cross machine locking of the database is beyond the scope of the software.
What sort of update rate are you doing? The other options that come to mind would be 'stat'ing the table before and after to make sure it had not been updated, or retrying the query if you get an error.
I have a similar scenario in which I have a texis database on a SAN volume mounted to server #1 and server #2 has a shared drive pointing to the database. I'm getting an error 'No such file or directory in the function ddopen' when running a vortex script on server #2 that queries the database. Is the fact that the server is using a shared drive that's causing this error?
What's the filename for the "no such file" message?
If you have full paths in your SYSTABLES or SYSINDEX tables then the full paths of the files must match on both systems. In general you should have relative paths.
