Open jadsy2107 opened 1 year ago
May i stress, it's working perfectly - and i'm using the data in Grafana to build dashboards
just the issue of restarting the stack, causes duplication of data ?
Great project! Big fan 👍
I checked the indices after about 10 minutes,
yellow open v_xml_cdr p1umAsPtRxSmS-67EZqlSQ 1 1 3322957 257988 1023.5mb 1023.5mb
Seems to have shrunken down to size, but still seems like theres duplicate data as the original sync wasn't that big
/usr/src/app/.fusionpbx_v_xml_cdr
that is accessible from the container?sorry about the delay
Hi @toluaina,
I'm experiencing similar issues. Pgsync itself works great, but any restart causes full sync, which takes some time. With larger datasets even up to 3+ hours.
When I test it locally:
How can I verify if it actually starts from where it left off?
I just found out that calling bootstrap process deletes checkpoint files. Should bootstrap be called only on demand when there are new indices added or schema is changed? If I run just pgsync command without calling bootstrap before it immediatelly starts continous sync.
PGSync version: Latest git branch 2.5.0
Postgres version: 13
Elasticsearch version: 8.9.2
Redis version: docker redis:alpine
Python version: docker python3.11-slim
Problem Description: Checkpoint file keeps getting deleted.
Error Message (if any): 2023-09-09 06:57:28.047:WARNING:pgsync.sync: Checkpoint file not found: /usr/src/app/.fusionpbx_v_xml_cdr
Dockerfile
docker-compose.yml
entrypoint.sh
schema.json
docker compose up
- brings up the stack and syncs fine, I just want it to work after reboots, without resyncing the entire data again,After the first startup, it takes around 10 minutes to sync (lots of data) and creates a checkpoint file which i can see at the mountpoint
.fusionpbx_v_xml_cdr
docker compose down
- the checkpoint file still exists when the stack is downed, however on the next startup it deletes this file and starts the sync from scratch, even duplicating data meaning that the data in elasticsearch is unreliable and incorrecthttp://localhost:9200/_cat/indices
yellow open v_xml_cdr p1umAsPtRxSmS-67EZqlSQ 1 1 3302175 0 937.5mb 937.5mb
after a second run, this grows to double the size...
What is your best advice ?
After first run and before shutdown:
After second startup:
Thanks in advance !!