|
I just ran into an odd replication error that I really wanted to post to see if anybody else had ever seen this. I ended up getting around it, but this was a first for seeing something like this. We had a new database we were extracting for a superintendent that had been out of the field for over two years. So we had shut his replication off. When they hired him back, we turned everything back on, made sure all the publications and subscriptions were set correctly, did a remote reset on his user, backed up the database, and started his extraction. Replication ran and everything was good. Or at least we thought it was good. I had kinda forgot to create his replication directory were we store all of our replication files. So when replication ran the first time for him, his directory did not exist. So I created his directory. My thought had been that it would realize that the file that had been sent was missing and it would just recreate it. The problem is that it didn't. I ran through 3 replication tests, and each time I received... I tried clearing the files out. Everything. It would recreate files and immediately come back to this error. I finally decided to remote reset and create the database again. This time after I created it, replication ran flawlessly. Has anybody else ever ran into an issue with a replication directory missing, causing an issue with it being unable to create the missing file? The environment we're running in is SQL Anywhere 12.0.1 Build 3942. Any thoughts on this would be appreciated. Like I said, I got around it. I'm really trying to attempt to understand what happened and if I possibly ran into something that might be a bug. Thanks everyone! Jeff Gibson |
|
OK I assume this is file based SQL Remote replication and you forgot to create the directories on the consolidated databases file system to accept the files the consolidated dbremote created when sending to the new remote. I also assume you extracted a new database for an already existing "SQL Remote User". I believe the issue you had was the process for reestablishing the remote user. Normally the initial replication file is 0-0000000000000 - some offset value - 0. I recommend deleting then re-creating the SQL Remote User and then performing your extraction process. On another note we have seen twice now when 12.0.1 creates two initial replication messages with the same 000 starting but different ending offset values, not sure what we are doing that causes this. Hope this helps. Jim
FWIW: That's a behaviour I have never noticed with v12.0.1. - Are you running 12.0.1.3152 in general? (I'm asking as that is the MR version, so a lot of v12.0.1 fixes might be missing, and there are some related to SQL Remote, see here...)
(23 Jun '15, 03:08)
Volker Barth
1
This is occurring on a server running 12.0.1.4104. I'll post another question when I'm able to get all the details.
(23 Jun '15, 07:14)
J Diaz
Replies hidden
Yes. You are correct. We are using file based replication. I didn't remove the user because they can't be because their security key is tied to a LOT of historical information in the database. However, I did remote reset the user again and extracted a new database. With the directory in place, everything worked just like it should. My curiosity was more of a "I wonder if anybody else had ran into problems with a replicating database if they had forgotten to set up the directory for the replicating user".
(23 Jun '15, 18:51)
Jeff Gibson
|
