I am currently using 3.13.4. But my database goes back to 3.8 when it started. On Wed, 08 Mar 2023, 20:10 Jake Van Meter, jvanmeter@users.sourceforge.net wrote: It is fine to clean these up manually. Out of curiosity, what version of SymmetricDS are you running? Orphaned SYM_DATA and SYM_DATA_EVENT https://sourceforge.net/p/symmetricds/discussion/739236/thread/3024bb4612/?limit=25#e1ac Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/symmetricds/discussion/739236/...
Doesn't seem to be doing that. I take it then that stranded rows can be safely removed. I suppose I will do a manual clean-up.
I recently discovered that I have millions of orphaned rows in SYM_DATA and SYM_DATA_EVENT. select count(*) from SYM_DATA_EVENT e where not exists (select 1 from SYM_OUTGOING_BATCH b where b.batch_id = e.batch_id); I imagine that this has been caused by the way in which we have been deleting stale nodes. That is, by deleting the related records in SYM_OUTGOING_BATCH instead of setting the status to 'OK'. The question that I need answered is: Is it safe to manually delete the rows in SYM_DATA_EVENT...
Is it possible to exclude certain columns from an initial load? The excluded columns must still sync on regular database updates. The reason I need this is that I have a table that contains BLOB data, which causes a massive payload for the initial load.
Thanks Eric for the detailed and comprehensive explanation. Conflict resolution of USE_PK_DATA and NEWER_WINS works best for my scenario. Although, conflicts should be rare, so that is something that I will need to investigate.
My App Server and Postgres Database are both hosted in the same MS Azure region. I think connectivity and latency are excellent. Is there any way to see if any of the data in sym_data is orphaned and can be removed? I think I have some more insight into what caused this spike in CPU. I updated my software which caused hundreds of thousands, if not millions, of events that needed to be sync'd. After 2 days, when these were all distributed to the various client nodes, the symptoms have gone away. However,...
My App Server and Postgres Database are both hosted in the same MS Azure region. I think connectivity and latency are excellent. Is there any way to see if any of the data in sym_data is orphaned and can be removed? I think I have some more insight into what caused this spike in CPU. I updated my software which caused hundreds of thousands, if not millions, of events that needed to be sync'd. After 2 days, when these were all distributed to the various client nodes, the symptoms have gone away. However,...
Version is 3.12.9 on Postgres 11.
I have noticed in the last few days that my Postgres database CPU runs at 100% during the online day. I also noticed that incoming batches are taking minutes to complete for just a few transactions. I think that this may be linked to a number of long running queries that I have seen in the log files; for example: 2021-05-25 19:56:53,491 INFO [home] [JdbcSqlTemplate] [home-dataloader-10] Long Running: (24440ms.) select source_node_id, create_time from sym_data where table_name = 'medical_exam_history_q_response'...
Hello Philip Thanks for the response. I think I wasn't clear in my original question. The specific scenario I have is that I upgraded Sym from 3.11.9 to 3.12.6 on an existing database. The initial load was done many months ago. Since the upgrade, it seems that the client thinks that an initial load is in progress.
Hi I'm looking for advice. I need to run a large update on my database, but do not want these updates to be sent to remote nodes. How can I disable triggers for 1 table... without losing legitimate triggers that are not part of these updates. Thanks
After upgrading from 3.11.9 to 3.12.6 I notice in the log files that the INFO message below is logged after each Pull request. What could be the cause? Is this causing any negative effects? 2021-02-13 14:56:46,045 INFO (db-pull-default-1) [org.jumpmind.symmetric.service.impl.PullService] Immediate pull requested while in reload mode
Thanks for the explanation. I use the node password as a way to control which remote nodes have the same database schema as the central node. So when I do a software update I change the node password to the software version number. The same process is followed on the client. Once both nodes are on the same version, synchronization resumes. Unfortunately some nodes can take some time to upgrade. Maybe there is a better way of doing this?
Hi It seems like something is ConfigurationChangedDataRouter to continuously trigger . I would be very grateful is someone could direct me where to look to fix this. 2021-02-05 08:11:39,753 INFO [home] [ConfigurationChangedDataRouter] [home-job-10] About to refresh the cache of node security because new configuration came through the data router
Awesome. Thanks! On 21 Feb 2015 7:17 PM, "Lukasz Lenart" lukaszlenart@users.sf.net...
Official Maven Plugin
runtimeBits to optionally prefer for 32 jvm over 64