I've recently had to deal with a sort of similar environment, though for different reasons. I ended up setting up a persistent ssh tunnel to the production ser

I've recently had to deal with a sort of similar environment, though for different reasons. I ended up setting up a persistent ssh tunnel to the production server with autossh, and then writing a miniature daemon that would regularly poll tables in the production server, figure out recent changes, and write the changes to a log. A secondary process would read the log and copy the changes into the development environment. By "regularly", I mean that it ran every minute. autossh was used to keep the resident sysadmin from complaining about thousands of ssh logins. It also made the first daemon a little easier to write, since from its perspective, it was still connecting to a local database. This worked surprisingly well. It wasn't fiddly or glitchy at all. Anytime there was a connection problem, things would stall for at most a few minutes until autossh could re-establish the connection, and then the reading daemon would happily work its way backward through the tables. Essentially this is just building out a master -> slave database relationship, but with application logic instead of reconfiguring the DB environment. It didn't require a very large time investment to get it working.