There is an ongoing effort to reduce the number of tables in the Metadb reporting database that are synchronized with FOLIO for updates to the data. This is done to improve the performance of Metadb overall. Also, some tables may be excluded to address problems impacting FOLIO applications.
The sys_quartz_mod_scheduler table needed to be added to the table exclusion list for Metadb with Sunflower -- the issues is not a new type of issue
We need to exclude tables in metadb that contain arrays and or byte type data (since they cannot be processed by metadb)
This is a new global schema we observe in sunflower.
So I believe simply excluding this is the solution
Also global schemas (in general) should be excluded from the sync/resync
This is the issue for supporting bytea data (which was observed in that table)
https://github.com/metadb-project/metadb/issues/88
| Date Excluded | Schema | Table | Size | Reason to Exclude |
|---|---|---|---|---|
| 8/5/25 | folio_inventory | instance_subject_source | This is being excluded temporarily as a fix for the lack of a primary key in the Data Import app development that causes replica identity errors while synchronizing | |
| 8/5/25 | folio_inventory | instance_subject_type | This is being excluded temporarily as a fix for the lack of a primary key in the Data Import app development that causes replica identity errors while synchronizing | |
| folio_source_record_manager | journal_records | 372 GB | ||
| folio_source_record_manager | all tables? | Do we need to synchronize any of these tables? | ||
| folio_audit | circulation_logs | 65 GB | ||
| folio_configuration | all tables? | Do we need to synchronize any of these tables? | ||
| folio_copycat | all tables? | Do we need to synchronize any of these tables? | ||
| old_records_tracking |