Обсуждение: rubyrep breaks Silver Stripe (MVC frame work) and vis versa.
Hi. I'm new to Postgresql, database replication and Silver Stripe. I have to provide a solution for real time database replication. I was using Rubyrep to do replication to a second database running as Hot standby / Master-Master. The developers failed to tell me that you can't use trigger based replication with a MVC frame work like Silver Stripe. After deploying new code / patched one must run a dev/build , which kicks of a process that rebuilds and adds to that database. This causes triggers to go missing and other things associated to Rubyrep to break. This resulted it corrupted data. And 2 days of work to fix it. Can some one suggest a replication solution. We are using a F5 appliance to provide fail over between 2 Postgresql 8.4.4 servers. It is currently configured to do a tcp connect to validate that primary server is up, if it can't reach the primary to switch to the secondary, thus real time replication and the secondary server being immediately available is critical. (later it's to be configured to query the database directly to validate that it is truly available.). I was looking at DRBD solutions but currently the network is configured such that multicast is not allowed and can not be reconfigured for the next couple of months until an outage can be scheduled. In short how can I get "Hot standby" / master-master replication that will be transparent to the changes made by Silver Stripe, that will work with Postgresql 8.4.4. Thanks G
On Thu, Jan 20, 2011 at 1:49 AM, Gregory Machin <gdm@linuxpro.co.za> wrote: > In short how can I get "Hot standby" / master-master replication that > will be transparent to the changes made by Silver Stripe, that will > work with Postgresql 8.4.4. > The only replication system I know of that does not need to be aware of the schema structure (and therefore must be aware of changes made to it) is the hot standby built into postgres. However, that does not get you master/master which you seem to want. I do not think your set of requirements can all be fulfilled. You will have to adjust one or more of them. I'll venture to say that the best target is to adjust the ORM's "update" process to be aware of your replication strategy, and work with it rather than assume it has full control over the DB.