Is this a new warm standby setup?
Have you been able to successfully replicate into the standby database in the past with this warm standby setup?
Did you by any chance run a switch active
command recently?
Assuming this is a new setup, and switch active
has not been run, I'm going to assume this may be an issue with how the standby connection was added to the setup ...
If the database connections have been added successfully and SRS thinks it should be replicating then admin logical_status
should show both connections with a status of Active
but this isn't the case ... the standby connection is showing Active/Waiting for Enable Marker
.
I'm guessing that when you added the standby connection you opted to initialize the standby database via a dump-n-load
operation. If you created the standby connection via a resource file you probably had something like rs.rs_init_by_dump: yes
in the resource file; if you ran rs_init
from the command line there would've been a related question that you probably said yes
to.
When you tell rs_init
that the standby database will be initialized via a dump-n-load
operation the standard scenario looks like:
- standby connection is created
- standby DSI is configured to discard all incoming transactions until it sees a
dump marker
admin logical_status
should show the standby connection with a status of Active/Waiting for Enable Marker
- operator performs a
dump database
in the active database (or dump transaction
if this is a largish db and a db dump has already been dumped and loaded into the standby database)
- the
dump {database|transaction}
command places a dump marker
in the active database's transaction log
- the repagent forwards this
dump marker
to SRS
- SRS forwards the
dump marker
to the DSI
- the DSI, upon receiving the
dump marker
will suspend the connection into the standby database and start saving incoming transactions
- operator loads the database (or transaction log) dump file into the standby database
- operator issues the
online database
command against the standby database
- operator resumes the DSI connection into the standby database
admin logical_status
should show the standby connection with a status of Active/
- the DSI starts applying transactions against the standby database
NOTE: I don't recall, off the top of my head, if the standby connection's status changes to Active/
a) upon receiving the dump marker
(and shutting down the DSI) or b) upon resuming the standby DSI connection.
Your admin logical_status
is showing us that the DSI is still waiting for a dump marker
.
If this is a production database you'll likely need to perform a new database dump ... at which point the standby DSI should go down ... and then you would need to load the database dump into the standby database, online said database, then resume the DSI connection into the standby database. This is the only way to ensure your standby database will be brought online with no missing transactions (ie, the current setup is discarding transactions).
If this is a development/test environment and/or you don't care about the possibility of the active and standby databases being out of sync, you should be able to:
- suspend the DSI into the standby database
- resume the DSI into the standby database
- verify
admin logical_status
now shows a status of Active/
for the standby database and if so ... and assuming no other issues ...
- newly performed transactions in the active database should start replicating
NOTE: Your previous DELETE
performed against the active database has probably been discarded by now so you'll probably want to start by manually running the same DELETE
against the standby in order to get the table in sync (assuming that's the only difference in the two tables, eg, you haven't run any UPDATEs
in the active database since turning on replication).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…