View Source

Sharon Markus (Beltaine) 10:47 AM

@John Malconian - Thank you so much for your help with Debezium. @Carole Godfrey from our hosting team is preparing for synchronizing our Metadb Test instance with our FOLIO Production instance. The Debezium connector reads the FOLIO database and populates Kafka with topic messages, which takes about 31 hours for Cornell's data, so that is okay. The part that is really slow is where Metadb is consuming the Kafka topics and populating the instance with either new data or changes to data. The most recent synchronization test took 8 days. We are trying to figure out why this is happening so we can get the sync down to a more reasonable timeframe, like 2 days. If you might be able to provide some insights and general guidance, that would be great. As I understand it, our hosting team is following the metadb documentation closely and running Metadb version 1.2 on an instance that meets the specs per the metadb documentation. Getting the synching and resynching down to shorter timeframes is our top priority right now. @Carole Godfrey and @nassib may have more comments/details here.

John Malconian 11:18 AM

Given that it takes 31 hours for Debezium to complete the initial snapshot, 6-8 days to complete the Metadb portion of the snapshot is about normal based on my experience as well depending on the data set. I think Nassib is better equipped to comment on Metadb performance specifically, but, generally speaking, it’s going to take longer for Metadb to consume the snapshot than Debezium. Metadb is doing data transformation and database operations that just take longer than reading a logical replication slot and pushing messages into Kafka. From an Ops perspective, ensure that the Metadb database is adequately sized to handle the processing (CPU) and that it is not hindered by I/O limitations. If using RDS for the Metadb database, provisioned IOPS or gp3 storage is best (I prefer gp3).

1

3 replies

Carole Godfrey 4 days ago

Ok, thank you -- we have monitored cpu usage (it did not go above ~26% during the initial sync process) and we are using gp3 storage.One thing that we are trying to test is the resync processMetaDB database has been populated from the initial sync and now we need to adjust and get in sync with an updated RDS instance (in this case - FOLIO has been upgrade from Orchid --> Poppy )In your experience, should a resync take the same or more/less time to complete as the initial sync?Thanks!

John Malconian 4 days ago

It’s going to take about the same time whether it’s an initial sync or re-sync. It’s essentially the same process either way.

11

Carole Godfrey 4 days ago

Ok thank youWe did get 1 resync running and trying to understand if it completed successfully -- but wasnt sure how I could confirm its successWe had gotten messages when running an endsync
I continued on from this step - but wasnt sure on queries or ? to confirm all is in syncTable sizes did not match up (when compared to FOLIO) -- but filtering __current = true

SELECT count(*) FROM folio_inventory.instance__ where __current = true;

SELECT count(*) FROM folio_inventory.instance__t__ where __current = true;

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

34% of current records have not been confirmed by the new snapshot.

The unconfirmed records will be marked as deleted.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

(edited)