|
We are seeing the following issue in our environment: Cons - ASA 11.0.1 remote -SA 12.0.1:3994 Insert is complete in remote and data is replicated back to the consolidate then a delete is replicated back to the remote however the table is not part of the publication to the remote. Data still exists in the consolidate but not the remote. I have translated the logs on both cons and remote. I don't see a delete in the consolidate but see the delete on the remote. I also see the delete coming through the Agent log file. Is this normal? |
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 09 May '14, 11:29
question was seen: 2,118 times
last updated: 09 May '14, 14:40
I'm confused. If the table is not part of the publication on the remote, why did the initial insert on the remote replicate to the consolidated?
It is not part of the publication on the cons to the remote.
Data replication only one way from the remote to the consolidate
No, this is not normal.
There isn't enough information here to for us to help you though. The following information would let us figure out exatly what is going on :
1) The reload.sql file generated by "dbunload -n" when run against the consolidated and remote databases. 2) Verbose dbremote output logs (i.e. dbremote -v) showing the consolidated database applying the insert, sending a message back down to the remote, and the remote database receiving the message that contains the delete.
The first two pieces of information is probably enough, but I'll add a third.
3) The transaction log from the consolidated database corresponding to the time in which dbremote ran against the consolidated database in which it received the insert and sent the delete. We want to actual transaction log, not the output from dbtran run against the transaction log.
Reg
Here's a WAG... maybe it is the silent resolution of a potential referential integrity violation on the remote that is causing an unexpected row deletion. I never have liked that "silent resolution" stuff, mostly because I can never figure out what hit me :)
Silent RI resolution is a dbmlsync thing, not dbremote. If there is a FKEY violation at the remote when dbremote is applying message, the statement fails.
I. 2014-05-09 13:32:30. Received message from "cons" (0-0000576800-0000577187-0)
I. 2014-05-09 13:32:30. Applying message from "cons" (0-0000576800-0000577187-0)
I. 2014-05-09 13:32:30. DELETE FROM cons.parent WHERE p_pkey=1000011
I. 2014-05-09 13:32:30. COMMIT
E. 2014-05-09 13:32:30. SQL statement failed: (-194) No primary key value for foreign key 'parent' in table 'child'
I. 2014-05-09 13:32:30. ROLLBACK
I. 2014-05-09 13:32:30. Applying message from "cons" (0-0000576800-0000577187-0)
I. 2014-05-09 13:32:30. DELETE FROM cons.parent WHERE p_pkey=1000011
I. 2014-05-09 13:32:30. COMMIT
E. 2014-05-09 13:32:30. SQL statement failed: (-194) No primary key value for foreign key 'parent' in table 'child'
I. 2014-05-09 13:32:30. ROLLBACK
"Ahhhh, the tag... pay attention to the tag, Breck" :)