• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

E9.2 AWS RDS Read Replica

Soumen

Reputable Poster
Dear Members,

Has anyone been able to use the RDS Read Replicas in JDE. To me this is easier said than done specially in case of JDE as it would be very difficult to manage the traffic based on nature of transaction. Any thoughts?

Thanks,
Soumen
 

JEMILLER

VIP Member
I will answer this question independent of AWS specifically as my answers apply to the use of a read-only replica on any JDE db platform in general. Most of these considerations can also be applied when trying to create a JDE read-only system for historical purposes that can still run reports. I use the below techniques when decommissioning JDE systems down to a single fat client or combo-box that can host a long term read-only environment for audit purposes.

1) You cannot run JDE batch jobs and many screens against a completely read-only database. You must have various work files and the next number tables (and possibly others depending on your use patterns) available for read/write. You would use standard CNC approaches with datasources and OCM mappings to manage table mappings for tables that must be read/write and those that can be read-only. Getting your RW and RO table mappings straight is a trial and error process. You need to run anything you want to work against the read-only replica and test. You may need to use debug logging to identify the tables that must be read-write.

2) Both Front-end access and batch access to a read-only replica for inquiry only. If I am able to cleanly separate a user base into update users and read-only users I will generally make use of a custom environment to control the mappings for the read-only view of the world and grant those users access to that environment only.

3) If you have some specific UBEs that are database intensive but non-update you can setup a dedicated batch server with OCM mappings within its server map that point to the read-only datasource(s) mentioned in #1. Jobs that run on this server via user submission or scheduling will then access the replica.

I have had a few sites that are data browser crazy and their heavy use of databrowser has impacted database performance and at times cause JAS server crashes. I have once applied the read-only approach to this with a dedicated url that referenced a read-only environment with a dedicated set of JVMs where databrowser was open for use. In the standard transactional environment it was not.

I have assumed with all of the above that you are chasing an actual database capacity or performance issue where offloading reporting to a read-only replica will deliver value. I would not recommend heading down this path if you aren't able to measure benefit as it is added technical complexity. In general I have found RDS to be pretty stunning in terms of performance and capacity.
 
Top