--- title: When Tungsten Replication "Stalls" but Nothing Has... description: A Tungsten Replicator stopped advancing its sequence number with no errors after an automated OS patching reboot. The root cause was MySQL answering... canonical: https://daily.dev/posts/when-tungsten-replication-stalls-but-nothing-has-failed-a-mysql-metadata-query-story-q4hq92oay twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: When Tungsten Replication "Stalls" but Nothing Has Failed: A MySQL Metadata-Query Story | daily.dev og:description: A Tungsten Replicator stopped advancing its sequence number with no errors after an automated OS patching reboot. The root cause was MySQL answering... og:url: https://daily.dev/posts/when-tungsten-replication-stalls-but-nothing-has-failed-a-mysql-metadata-query-story-q4hq92oay og:image: https://api.daily.dev/og/posts/q4hq92oay.png og:image:alt: When Tungsten Replication "Stalls" but Nothing Has Failed: A MySQL Metadata-Query Story og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # When Tungsten Replication "Stalls" but Nothing Has Failed: A MySQL Metadata-Query Story **[Planet MySQL](https://daily.dev/sources/planet-mysql)** · 10 min read · 0 upvotes · 0 comments ## Summary A Tungsten Replicator stopped advancing its sequence number with no errors after an automated OS patching reboot. The root cause was MySQL answering information_schema.columns metadata queries in ~10 seconds each instead of milliseconds after a rushed restart, combined with a cold metadata cache that needed to rebuild across many shards. The fix was a clean deliberate reboot of the full stack. A deeper preventive fix is enabling the optimized metadata query (available since Tungsten 7.0.0) via a single property, which replaces LIKE pattern matching with exact equality comparisons, turning a full scan of ~120,000 rows into a single primary-key lookup and dropping query time from ~0.09s to effectively 0.00s. Additional advice covers startup sequencing after patches and removing legacy replication channels that add log noise. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I enable the optimized metadata query in Tungsten Replicator to avoid slow information_schema lookups? Set the property replicator.datasource.global.connectionSpec.usingOptimizedMetadataQuery=true in tungsten.ini. This replaces LIKE pattern matching with exact equality comparisons on table_schema and table_name, turning a full scan of ~120,000 rows (hash join, type=ALL) into a single eq_ref primary-key lookup. Measured execution time drops from ~0.09s to effectively 0.00s. The option is available from Tungsten 7.0.0 onward but is off by default due to edge cases with multibyte identifiers. _Teams running heavily sharded MySQL schemas track Tungsten configuration trade-offs like this on daily.dev._ ### Why does Tungsten Replicator query information_schema.columns and what happens to that cache on restart? Tungsten queries information_schema.columns to resolve column names and types from raw row-based binary log events, which contain values but not column names. It caches results in memory to avoid per-event lookups. The cache is invalidated on DDL changes (single table) or on replicator restart (entire cache). After a restart, every table touched must re-fetch its metadata, so if MySQL is slow to answer those queries, apply throughput collapses until the cache is rebuilt. _Developers managing MySQL replication pipelines find root-cause analyses like this one on daily.dev._ ### How do I diagnose a Tungsten Replicator stall where the sequence number is not advancing but no error is reported? Run SHOW FULL PROCESSLIST on the target database during the stall and look for long-running INFORMATION_SCHEMA.COLUMNS queries. If multiple unrelated clients (e.g., both the replicator and a downstream connector like GCP Datastream) are all slow on metadata reads simultaneously, the problem is MySQL's internal metadata performance, not a replication fault. A single processlist snapshot is usually enough to distinguish a MySQL metadata-performance issue from a genuine replication error. _When a replication stall has no obvious error, engineers debugging MySQL pipelines find diagnostic patterns like this on daily.dev._ ## Similar posts on daily.dev - [How Meta Rebuilt Data Ingestion for Petabyte-Scale Reliability](https://daily.dev/posts/how-meta-rebuilt-data-ingestion-for-petabyte-scale-reliability-hjqu3p98k) · InfoQ · 0 upvotes · 0 comments - [The Night Our Tables Wouldn't Stop Growing](https://daily.dev/posts/the-night-our-tables-wouldn-t-stop-growing-pvfggogkk) · Planet PostgreSQL · 1 upvotes · 0 comments - [Resolving PostgreSQL replication lag with heartbeat tables in change data capture scenarios](https://daily.dev/posts/resolving-postgresql-replication-lag-with-heartbeat-tables-in-change-data-capture-scenarios-qugpegqxv) · AWS Database Blog · 1 upvotes · 0 comments - [Understanding MySQL Replication "fatal error 1236": "Replica has more GTIDs than the source has, using the source's SERVER\_UUID"](https://daily.dev/posts/understanding-mysql-replication-fatal-error-1236-replica-has-more-gtids-than-the-source-has-usi-3znrq1oru) · Planet MySQL · 0 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#mysql](https://daily.dev/tags/mysql) [View this post on daily.dev](https://daily.dev/posts/when-tungsten-replication-stalls-but-nothing-has-failed-a-mysql-metadata-query-story-q4hq92oay) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"When Tungsten Replication \"Stalls\" but Nothing Has Failed: A MySQL Metadata-Query Story","url":"https://daily.dev/posts/when-tungsten-replication-stalls-but-nothing-has-failed-a-mysql-metadata-query-story-q4hq92oay","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/when-tungsten-replication-stalls-but-nothing-has-failed-a-mysql-metadata-query-story-q4hq92oay"},"datePublished":"2026-08-06T23:24:49.003Z","dateModified":"2026-08-06T23:25:24.800Z","description":"A Tungsten Replicator stopped advancing its sequence number with no errors after an automated OS patching reboot. The root cause was MySQL answering...","image":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","thumbnailUrl":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","isAccessibleForFree":true,"articleSection":"Planet MySQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet MySQL","logo":"https://media.daily.dev/image/upload/s--UKAtmXTq--/f_auto,q_auto/v1780213421/logos/planet-mysql?_a=BAMAMiWQ0","url":"https://daily.dev/sources/planet-mysql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/when-tungsten-replication-stalls-but-nothing-has-failed-a-mysql-metadata-query-story-q4hq92oay","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,mysql","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet MySQL","item":"https://daily.dev/sources/planet-mysql"},{"@type":"ListItem","position":3,"name":"When Tungsten Replication \"Stalls\" but Nothing Has Failed: A MySQL Metadata-Query Story"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/when-tungsten-replication-stalls-but-nothing-has-failed-a-mysql-metadata-query-story-q4hq92oay#faq","mainEntity":[{"@type":"Question","name":"How do I enable the optimized metadata query in Tungsten Replicator to avoid slow information_schema lookups?","acceptedAnswer":{"@type":"Answer","text":"Set the property replicator.datasource.global.connectionSpec.usingOptimizedMetadataQuery=true in tungsten.ini. This replaces LIKE pattern matching with exact equality comparisons on table_schema and table_name, turning a full scan of ~120,000 rows (hash join, type=ALL) into a single eq_ref primary-key lookup. Measured execution time drops from ~0.09s to effectively 0.00s. The option is available from Tungsten 7.0.0 onward but is off by default due to edge cases with multibyte identifiers. Teams running heavily sharded MySQL schemas track Tungsten configuration trade-offs like this on daily.dev."}},{"@type":"Question","name":"Why does Tungsten Replicator query information_schema.columns and what happens to that cache on restart?","acceptedAnswer":{"@type":"Answer","text":"Tungsten queries information_schema.columns to resolve column names and types from raw row-based binary log events, which contain values but not column names. It caches results in memory to avoid per-event lookups. The cache is invalidated on DDL changes (single table) or on replicator restart (entire cache). After a restart, every table touched must re-fetch its metadata, so if MySQL is slow to answer those queries, apply throughput collapses until the cache is rebuilt. Developers managing MySQL replication pipelines find root-cause analyses like this one on daily.dev."}},{"@type":"Question","name":"How do I diagnose a Tungsten Replicator stall where the sequence number is not advancing but no error is reported?","acceptedAnswer":{"@type":"Answer","text":"Run SHOW FULL PROCESSLIST on the target database during the stall and look for long-running INFORMATION_SCHEMA.COLUMNS queries. If multiple unrelated clients (e.g., both the replicator and a downstream connector like GCP Datastream) are all slow on metadata reads simultaneously, the problem is MySQL's internal metadata performance, not a replication fault. A single processlist snapshot is usually enough to distinguish a MySQL metadata-performance issue from a genuine replication error. When a replication stall has no obvious error, engineers debugging MySQL pipelines find diagnostic patterns like this on daily.dev."}}]} ```