hi!
I've recently found dbreplicator, and with some minor bumps, I managed to make it work.
Now I have a problem not (yet) mentioned in the forum. I'm using PostgreSQL 8.0.15 in Gentoo Linux and I'm trying to replicate a database that has tables with fields that are of bytea type, to support binary files. During the snapshot process, the application stopped on one of those tables, with the following error: ERROR: column "picture" is of type bytea but expression is of type bigint
Is this a bug or limitation of dbreplicator? I really hope there is a solution for this, as I found it to be the best replication solution for me so far.
Thanks in advance!!!
I am having the same problem
I am having the same problem with PostgreSQL DB. Is there a way around this since DBReplicator really does evrything I need?
it may work for you
hi gox!
Im glad to know that Im not alone on this. I was beginning to think that I was doing something wrong.
I dont know if you noticed yet, but this type of data can be replicated with a pull. If its possible for your case, in order to make it work, you can get the snapshot of an empty database publication and then add the records to the publisher, and do a pull on the subscriber. I've tested it and saw that my pictures were replicated to the subscriber.
Unfortunately, I cant use this solution, because the db I want to replicate already has a lot of data and this wont work with pg_dump/pg_restore. :(
If you come up with any ideas, it will be welcome.
I just wish that the developer would contact with us in order to get us a solution. I think its not difficult, because if the Pull method works, the Snapshot method should work too.
Regards
i think i got it
hey pjam!
Thanks for your reply. I did realize that the pull will replicate the bytea fields.
However, I also had a problem with taking the snapshot of the database with huge amount of rows with bytea data already stored. I did manage to solve this problem by filling out the table rep_ignoredcolumnstable which is located in your public schema. Simply, you want to find the desired table (the one containing a bytea field) and its value in rep_table_id field which are stored in rep_reptable table also located in public schema. Then add a new row in table rep_ignoredcolumnstable and fill it out with rep_table_id and column name for your bytea field. This should work for the snapshot. When the snapshot is taken successfully remove these rows from rep_ignoredcolumnstable table and set your replication schedule or manually push and pull your data.
I hope this will help you.
Greetingz
hi again! thanks for that
hi again!
thanks for that workaround! but unfortunately, that wont solve my problem as the pull process wont replicate the bytea data already stored. :(
thanks anyway
Didn't you say you already
Didn't you say you already managed to pull the bytea data?
I am asking this because you suggested for me to do that and I also succeed with "pulling" bytea fields. Only problem I had was to take the snapshot because of the bytea fields but after I bypassed the columsn with bytea fields I was able to pull bytea data regularly.
yes i did, but i did it only
yes i did, but i did it only for new inserted data. I want to replicate the already inserted bytea data, and with your method it does not do it. The pull method wont pull the bytea data. It worked for you like this?
I do see where are you
I do see where are you coming from and this will work not only with inserted data but it will replicate an updated rows. So what you can do is take one column, update it with new value and then pull the data. By updating it, trigger will populate the shadow tables and your bytea fields will also be included. Later when you pull the data you will also pull the bytea field values.
DBReplicator is a powerful
DBReplicator is a powerful application for network-based multi-master heterogeneous database replication or filtered synchronization. DBReplicator is a powerful application for network-based multi-master heterogeneous database replication or filtered synchronization. It supports heterogeneous replication, bi-directional data synchronization between any of the supported database backends, application swatch watches independence, automatic conflict detection and resolution, a scheduling facility, verbose debugging using Apache log4j, special characters, and automatic table creation.