Transcript OpenEdge Replication made easy

OpenEdge Replication Made Easy
Adam Backman
White Star Software
[email protected]
Agenda
• Setup
– System
– Database
– Replication
• Maintenance
• Transition
• Common recovery
scenarios
• Conclusion
What is it?
and
Why Do I Need it?
Types of System Replication
• True failover
– Run the entire operation
• Partial failover
– Run core services only in failover mode
• Recovery
– The target machine is essentially a backup
• Asynchronous vs. Synchronous
Setup: System
• Operating system
• Hardware
– Disk
– Other resources
• Support software
Setup: Operating System
• Operating system version
• Patches
• Same Kernel parameters
Two Reasons
– Nothing unexpected when you fail over
– Easier to maintain if both machines are identical
Setup: Disk
• Both machines need the same storage
capacity (DB, application, temp files, …)
• Source machine can use 200 GB drives and the
target can use 1TB drives
• This will affect performance in the event of a
failover but you can choose to run only core
services in failover mode
Setup - Other Resources
CPU, Memory
– Need to support replication
• Single fast CPU on replication machine
• Multiple CPUs in Production
– Need to support all or some of your users
depending on your recovery plan
Setup: Support software
• Fax
• EDI
• PostalSoft
• All software must be purchased and
configured if your failover plan includes
moving the users to the replication machine
Setup: Database
• Must have an existing comprehensive
recovery plan in place
• Must have multi-volume after image setup
• Target database *should* have the same
structure definition as the source
Setup: Replication
• We will get to the database in a minute but
you need to also plan for replication of other
portions of the system.
• Options:
– Remote mirrors (hardware)
– Operating system commands (Example: rsync)
– Any others?
Asynchronous Replication
• Also know as log-based replication
• Not true replication but a point in time
synchronization between two machines
• After image files are taken from the source
machine and applied throughout the day
• Pros:
– Cheap
• Cons:
– Not synchronous
– Must maintain the code yourself
OpenEdge Replication
This is a feature/product from Progress that
provides real-time synchronization between
two or more databases. There is a replication
server (source) and one or two replication
agents (targets).
What is OpenEdge Replication?
After
Image
Users doing
work
Source
DB
OE
Replication
Server
OE
Replication
Agent(s)
Target
DB(s)
Pros and Cons: OpenEdge
Replication
• Pros
– Supported product (10.1 and above is best)
– Real-time replication
– Supports reporting on the target side
• Cons
– Not free (REALLY NOT FREE)
– Need to learn another set of utilities
– No support (currently) for asynchronous
replication
Initial Setup: OpenEdge
Replication (Offline)
• After imaging must be enabled for the source database
• With the database down you can enable site replication
for the source database
proutil <dbname> –C enablesitereplication source
• Move the properties files into place Currently the same
directory as the DB
• Start the source database with -DBService replserv and
-pica parameters
• Do an online backup of the source
• Restore the backup to the target
-pica
• Determines the size of the interprocess
communication queue between the RDBMS
and the replication server
• Default value 64k in 10.1C+ and 6k before
• Default value is generally too low
• Always set it to it’s maximum value
– In 10.1C+ set it to 8192 (8MB)
– Prior to 10.1C set it to 2048
Initial Setup: OpenEdge
Replication (Online)
• Enable After Imaging (If necessary)
• Put the replication properties files in place
• You need to use deferred agent startup
[server]
defer-agent-startup=<number-of-minutes>
Note: number of minutes must be between 0 and 10080 (1 week)
• Enable replication
proutil <dbname> -C enablesitereplication source
• Do an online backup to build target database
proutil online <source-db> <bkup_file> -REPLTargetCreation
Initial Setup: OpenEdge
Replication (continued)
• After the restore to the target is complete
• Enable site replication on the target
proutil <dbname> –C enablesitereplication target
Or
prorest <dbname> <backupname> -REPLTransition
• Start the target with -DBService replagent and -S <service
or port number> parameters
• Use the dsrutil utility to monitor replication
dsrutil <dbname> –C monitor
• Or look for the following message in the
target database .lg file
“The Source and Target databases are synchronized. (10668).”
Setup: OpenEdge properties files
• Server Properties File
• Agent Properties File(s)
Example: source.repl.properties
[server]
control-agents=agent1
database=source
transition=manual
transition-timeout=600
[control-agent.agent1]
name=agent1
database=source
host=moth
port=4501
connect-timeout=120
replication-method=async
critical=0
Example: target.repl.properties
[agent]
name=agent1
database=source
listener-minport=4387
listener-maxport=4500
Maintenance Issues: OpenEdge
Replication
• Fathom replication does not support 2-phase
commit
• Index rebuild will require a initialization of the
replication process (Use: index compact)
• Index and table moves must be done in multiuser mode
• Generally, changes to the database must be
done in multi-user mode as the broker is the
mechanism that starts replication
After image file status
• Empty
– Ready for use
• Busy
– Currently being used
• Full
– Closed and applied to target
• Locked (Replication only)
– Closed and not yet applied to target
Maintenance
• Is replication running?
• Other replication maintenance
• How to do common maintenance tasks
– Add extents
– Index rebuild
Monitoring Replication
• Use the dsrutil utility with the monitor option
dsrutil <dbname> -monitor
• This can be done on the source or target side
Monitoring: Server
Site Replication Monitor Version 2 Page 1
Database: /data/source_db
Database is enabled as Fathom Replication:
Source
Server is:
Normal processing
Number of configured agents:
1
Defer Agent Startup :
Continue connection attempts until:
Mon Nov 7 11:59:55 2005
Deferred Agent Startup will expire in :
1 Hr 14 Min 44 Sec
Next connection attempt in :
30 Seconds
Connections attempts performed
1
Agent(s) currently connected
0
Delay Interval (current / min / max):
25 / 5 / 500
Recovery information
State:
No recovery being performed
Agents needing recovery:
0
Agents connected:
0
Agents in synchronization:
0
Transition information:
Type:
Manual
Transition timeout limit:
600 seconds
Source: Progress Fathom Replication User Guide
Monitoring: Agent
Site Replication Monitor Version 2 Page 1
Database: /data/source_db
Agent:
Name:
agent1
ID:
1
Host name:
localhost
Target database:
target_db
State:
Normal processing
Critical:
No
Method:
Asynchronous
Remote agent is:
Connected via broker
Source and target are synchronized
In normal processing
Remote agent is waiting for:
Nothing
Recovery state:
No recovery being performed
Maximum bytes in TCP/IP message:
30720
Server/Agent connection time:
Mon Oct 31 14:50:58 2005
Server/Agent connection timeout:
120.000 seconds
Transition information:
Type:
Manual
Timeout limit:
0 seconds
The last block was sent at:
Mon Oct 31 14:57:42 2005
Activity information:
Blocks sent:
720
Blocks acknowledged:
28
Synchronization points
12
AI Block Information:
Current RDBMS Block (Seq / Block):
5 / 1923
Last Sent Block (Seq / Block):
5 / 1923
Server to agent load check interval:
10 blocks
Time between server and agent load checks:
5.597 seconds
Time taken to respond to load check:
0.178 seconds
Source: Progress Fathom Replication User Guide
Other DSRUTIL Option
applyextent
Manual application of source AI extents to the target database.
canceldefer
Do not attempt reconnect to deferred replication agent.
connectagent or startagent
Start agent(s).
disablesitereplication
Online disable of replication on the source database.
recovery
Displays the replication recovery information.
Other DSRUTIL Option
relwaits
Release any waits so that database activity can continue.
restart
Restart replication server.
terminate
Terminates replication server or agent.
transition
Transition agent to a replication-enabled database.
triggertransition
Places the target database into a pre-transition state.
Transition
• Database Roles
• Changing roles
• How to transition
– Auto
– Manual
Database Roles
• Primary database - The database your
application interacts with. Used as a source in
normal operations mode
• Secondary database - The database that acts
as a target in normal operations mode
• These roles do not change but in transition
the Primary database can act as a target while
the Secondary database interacts with your
application
Failover
• Primary database fails
• If primary machine is available apply last
transactions
dsrutil <dbname> -C applyextent <extentname>
• Then transition the database
dsrutil <dbname> -C transition [failover]
[failover] will transition the target via the replication agent
then transition the source. If replication is not running you
cannot use the failover option
Failback
•
•
•
•
No activity on the databases
No users on the database
Run “dsrutil <dbname> -C transition failover”
This will transition the primary database (now
target) to transition to a source and then
transition the secondary database (no a
source) to a target.
• If you have “restart-after-transition” set in the
properties files then the databases will be
restarted in their proper roles
Points to Remember
• Start with a good backup plan
• You must have multi-volume AI
• Choose a replication method that makes sense
for you
• If you choose OpenEdge Replication use
asynchronous replication for performance
reasons
• Test extensively before doing replication in
your production environment
Questions?
Adam Backman
[email protected]
Thank you for
your time!