Stay organized with collections
Save and categorize content based on your preferences.
If a problem occurs while a stream is transferring data from a source database
into a destination, the stream can enter a Failed or Failed permanently state.
In both cases, you can rectify the problem.
Troubleshoot a stream
Go to the Streams page in the Google Cloud Console.
Click the Column display options icon in the upper-right corner of the page. The icon appears as three vertical columns.
If it isn't selected, select the Status checkbox, and then click OK. Datastream displays the following statuses:
Failed: for an error that occurs on a Running stream. Such errors
imply that the stream is still active or continuously attempting to run.
Failed permanently: for a stream that can't continue to run. Such errors
might cause data loss.
Click the stream that you want to troubleshoot. Any errors associated with the stream appear on the Stream details page.
For example, if Datastream can't connect to the source database, then the We can't use the credentials that you provided to connect to the data source. error message appears on this page.
Address the errors. You can resolve errors for either the stream or the connection profile.
For example, if errors are associated with either the source data objects of the stream or its destination configuration information, then modify the stream.
If errors are associated with the connectivity information of the stream, then update the configuration information about the source database or the destination for any connection profiles being used by the stream.
Fix the Failed stream so that it can automatically resume, or recover
the Failed permanently stream.
Recover a stream
The first thing to try when recovering a stream is to recover it from the current
position. For more information about stream recovery options, see Stream recovery
overview.
If recovering a stream from the current position fails, then try the following:
Drop or truncate the affected tables in the destination. You need to do this
because while the stream was down, Datastream might have missed some
DELETE events. DELETE events can't be recovered if you don't truncate the table
before performing the backfill.
Recover the stream from the most recent position. For PostgreSQL, recreate the
replication slot or create a new replication slot.
Once the stream is running, trigger backfills to restore all historical data.
For information about how to trigger a backfill, see Initiate backfill.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eStreams transferring data can enter a \u003ccode\u003eFailed\u003c/code\u003e or \u003ccode\u003eFailed permanently\u003c/code\u003e state if an error occurs, both of which can be rectified.\u003c/p\u003e\n"],["\u003cp\u003eThe status of a stream can be checked on the \u003cstrong\u003eStreams\u003c/strong\u003e page in the Google Cloud Console, which will display either a \u003ccode\u003eFailed\u003c/code\u003e or \u003ccode\u003eFailed permanently\u003c/code\u003e status.\u003c/p\u003e\n"],["\u003cp\u003eErrors associated with a stream are displayed on the \u003cstrong\u003eStream details\u003c/strong\u003e page, such as Datastream being unable to connect to the source database, and can be addressed by modifying the stream or its connection profile.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eFailed\u003c/code\u003e streams can be fixed to automatically resume, while \u003ccode\u003eFailed permanently\u003c/code\u003e streams require recovery, starting with recovery from the current position.\u003c/p\u003e\n"],["\u003cp\u003eRecovering a \u003ccode\u003eFailed permanently\u003c/code\u003e stream may require dropping or truncating affected tables in the destination and triggering backfills to restore historical data.\u003c/p\u003e\n"]]],[],null,["# Troubleshoot a stream\n\nIf a problem occurs while a stream is transferring data from a source database\ninto a destination, the stream can enter a `Failed` or `Failed permanently` state.\nIn both cases, you can rectify the problem.\n\nTroubleshoot a stream\n---------------------\n\n1. Go to the **Streams** page in the Google Cloud Console.\n\n [Go to the Streams page](https://console.cloud.google.com/datastream/streams)\n2. Click the **Column display options** icon in the upper-right corner of the page. The icon appears as three vertical columns.\n\n3. If it isn't selected, select the **Status** checkbox, and then click **OK**. Datastream displays the following statuses:\n\n - `Failed`: for an error that occurs on a `Running` stream. Such errors imply that the stream is still active or continuously attempting to run.\n - `Failed permanently`: for a stream that can't continue to run. Such errors might cause data loss.\n4. Click the stream that you want to troubleshoot. Any errors associated with the stream appear on the **Stream details** page.\n\n For example, if Datastream can't connect to the source database, then the **We can't use the credentials that you provided to connect to the data source.** error message appears on this page.\n5. Address the errors. You can resolve errors for either the stream or the connection profile.\n\n For example, if errors are associated with either the source data objects of the stream or its destination configuration information, then [modify the stream](/datastream/docs/modify-a-stream#modifyastream).\n\n If errors are associated with the connectivity information of the stream, then update the configuration information about the [source database](/datastream/docs/modify-a-stream#modifystreamsourceinfo) or the [destination](/datastream/docs/modify-a-stream#modifystreamdestinfo) for any connection profiles being used by the stream.\n | Any changes that you make to a single connection profile affect all streams using that connection profile.\n\n \u003cbr /\u003e\n\n6. Fix the `Failed` stream so that it can automatically resume, or [recover](/datastream/docs/recover-a-stream)\n the `Failed permanently` stream.\n\n### Recover a stream\n\nThe first thing to try when recovering a stream is to recover it from the current\nposition. For more information about stream recovery options, see [Stream recovery\noverview](/datastream/docs/recover-a-stream#recovery-overview).\n\nIf recovering a stream from the current position fails, then try the following:\n\n1. Drop or truncate the affected tables in the destination. You need to do this because while the stream was down, Datastream might have missed some `DELETE` events. `DELETE` events can't be recovered if you don't truncate the table before performing the backfill.\n2. Recover the stream from the most recent position. For PostgreSQL, recreate the replication slot or create a new replication slot.\n3. Once the stream is running, trigger backfills to restore all historical data. For information about how to trigger a backfill, see [Initiate backfill](/datastream/docs/manage-backfill-for-the-objects-of-a-stream#initiatebackfill).\n\nWhat's next\n-----------\n\n- To learn more about streams, see [Stream lifecycle](/datastream/docs/stream-states-and-actions).\n- To learn how to modify a stream, see [Modify a stream](/datastream/docs/modify-a-stream).\n- To learn how to recover a failed stream, see [Recover a stream](/datastream/docs/recover-a-stream)."]]
