實時同步任務支持哪些數(shù)據(jù)源？

實時同步支持的數(shù)據(jù)源請參考文檔：實時同步支持的數(shù)據(jù)源。

為什么實時同步任務延遲較大？

當您在查詢實時同步任務產(chǎn)出的表數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)未同步時，原因可能是實時同步任務出現(xiàn)延遲，您可以進入運維中心的實時同步任務界面，查看任務的業(yè)務延遲數(shù)值是否過大。詳情請參見實時同步任務延遲解決方案。

若業(yè)務延遲較大，其可能原因如下：

實時同步任務為什么不建議使用公網(wǎng)？

實時同步任務使用公網(wǎng)時，會存在以下風險：

• 網(wǎng)絡可能不穩(wěn)定，丟包等時常發(fā)生，影響同步性能。

• 安全性不高。

實時同步字段格式問題

數(shù)據(jù)集成實時同步在同步MySQL、Oracle、Loghub和PolarDB類型的數(shù)據(jù)至DataHub或Kafka時，會在同步的目標端添加5個附加列，以進行元數(shù)據(jù)管理、排序去重等操作。詳情請參見實時同步字段格式。

實時同步數(shù)據(jù)時，如何處理TRUNCATE？

實時同步支持TRUNCATE的，在增全量合并的時候會生效。如果選擇忽略TRUNCATE，可能會導致進行實時數(shù)據(jù)同步時出現(xiàn)多的數(shù)據(jù)。

如何提高實時同步的速度和性能？

如果同步寫入速度較慢，可以適當增加寫入端并發(fā)數(shù)，調整JVM參數(shù)，JVM參數(shù)與同步庫數(shù)量無關，和變更頻率有關。在當前資源組機器允許情況下，內存給的越大，F(xiàn)ull GC頻率會越小，實時同步性能相應也會越高。

實時同步是否支持在界面運行？

實時同步不支持在DataWorks的界面上直接運行，您需要在配置好實時同步任務后，提交并發(fā)布實時同步節(jié)點后，進入生產(chǎn)環(huán)境運行該節(jié)點。詳情請參見實時同步任務運維。

實時同步MySQL數(shù)據(jù)源時速度為什么會變慢？

原因之一就是同步的binlog變多，因為binlog是實例級別，即便配置的同步任務只同步了表A，那么沒有在任務中的表B、表C等如果發(fā)生變更，也會生成binlog，這些額外增加的binlog就會使同步處理的速度變慢。

實時同步中選擇單庫與選擇多庫的內存占用模式為什么會有差異？

選擇大于等于2個庫時就進入了“整實例”實時同步的模式，此時資源的占用要高于2個單獨只有一個庫的實時任務。

實時同步任務DDL策略都有哪些？

處理方式如下：

DDL類型劃分：

寫入目標數(shù)據(jù)源時，對源端DDL及DML操作的注意事項

• 當源端新增列，并在目標端正常執(zhí)行后，會有以下限制：

  • 當新增DEFAULT VALUE列后，目標表該新列不會有值，會一直為NULL，后續(xù)當源端新增列中新增數(shù)據(jù)時，實時同步任務會將新增數(shù)據(jù)同步至該列。

  • 當新增VIRTUAL列后，目標表該新列不會有值，會一直為NULL，后續(xù)當源端新增列中新增數(shù)據(jù)時，實時同步任務會將新增數(shù)據(jù)同步至該列。

• MySQL和PolarDB MySQL源端實時同步，建議您在源端新增列時采用末尾追加列方式，不要采用在中間字段加列方式。如果源端無法避免中間字段加列，需要注意以下約束條件：

  • 全增量解決方案中，在全量同步階段不要進行中間字段加列，否則會導致實時同步階段數(shù)據(jù)異常。

  • 實時同步階段，同步位點重置時間需要設置在中間字段加列DDL事件之后，否則會導致后續(xù)實時同步數(shù)據(jù)異常。

• 如果發(fā)生數(shù)據(jù)異常，可以重新進行全量數(shù)據(jù)初始化方案（只需要將中間加列的表剔除，然后重新進行數(shù)據(jù)初始化，不需要將整個任務所有表進行全量初始化），恢復正確數(shù)據(jù)。

源表有默認值，通過數(shù)據(jù)集成創(chuàng)建的目標表，默認值、非空屬性等會保留嗎？

創(chuàng)建目標表時候，DataWorks只會保留源表的列名、數(shù)據(jù)類型、注釋等信息，不會保留源表的默認值、約束（包含非空約束、索引等）。

讀取Postgres的實時同步任務Failover了，延遲為什么很大？

這是Postgres本身數(shù)據(jù)庫的特性，如果接受不了延遲，您可以停止任務，并重新啟動任務做一次全增量數(shù)據(jù)同步。

實時同步MySQL數(shù)據(jù)源的數(shù)據(jù)時，一開始讀到數(shù)據(jù)，一段時間后無法讀到數(shù)據(jù)，怎么處理？

1. 可在數(shù)據(jù)庫執(zhí)行以下命令，查看當前這個數(shù)據(jù)庫實例正在寫入的binlog文件。

   show master status 

2. 對比日志中讀到的binlog文件，在日志中搜journalName=MySQL-bin.000001,position=50，確認是否有數(shù)據(jù)寫入數(shù)據(jù)庫。

3. 如果有數(shù)據(jù)在寫入，但是binlog卻沒有往前推進，請聯(lián)系DBA處理。

實時同步Oracle、PolarDB、MySQL任務重復報錯

• 現(xiàn)象：實時同步任務重復報錯。

  實時同步來源為Oracle、PolarDB、MySQL數(shù)據(jù)源時，默認不支持處理源端DDL消息，當進行除新建表以外的DDL變更時，實時任務將報錯退出。斷點續(xù)傳情況下，可能存在源端未產(chǎn)生DDL消息，但同步仍然報錯的情況。

  說明

  為避免數(shù)據(jù)在某時間段內丟失或錯亂，禁止使用Rename命令將兩列的名稱互換。例如，將A列和B列的列名做了調換操作。

• 原因：由于實時同步支持斷點續(xù)傳，為保障不丟失數(shù)據(jù)，在重啟實時同步回溯位點時可能會往前回溯一部分數(shù)據(jù)，此過程可能導致之前的DDL消息再次被讀取而再次報警。

• 解決方案：

  1. 當源端產(chǎn)生DDL變更時，手動在目標端數(shù)據(jù)庫進行相應的DDL變更。

  2. 啟動實時同步任務并變更DDL消息處理策略，由出錯改為忽略。

     說明

     由于斷點續(xù)傳還會訂閱到該DDL事件，為了避免任務依然失敗，所以暫時改為忽略。

  3. 停止實時同步任務并再次修改DDL消息處理策略，由忽略還原為出錯，并再次重啟實時同步任務。

Kafka實時同步報錯： Startup mode for the consumer set to timestampOffset, but no begin timestamp was specified.

請重置啟動位點。

MySQL實時同步報錯：Cannot replicate because the master purged required binary logs.

MySQL實時同步報錯：Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup.時，可能是因為在MySQL未找到消費位點的binlog記錄，請檢查您MySQL的binlog保留時間，同步任務啟動時請將該位點配置在這個時間范圍內。

MySQL實時同步報錯：MySQLBinlogReaderException

MySQL實時同步報錯：MySQLBinlogReaderException: The database you are currently syncing is the standby database, but the current value of log_slave_updates is OFF, you need to enable the binlog log update of the standby database first. 時，可能是因為備庫沒有開啟binlog，如果您要同步備庫，需要做備庫級聯(lián)開啟binlog，可以找DBA尋求幫助。

開啟binlog的操作詳情可參見步驟3：開啟MySQL的Binlog。

MySQL實時同步報錯：show master status' has an error!

MySQL實時同步報錯：show master status' has an error!，報錯詳情為Caused by: java.io.IOException: message=Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation, with command: show master status時，可能是因為數(shù)據(jù)源沒有開啟對應數(shù)據(jù)庫的權限。

數(shù)據(jù)源配置賬號需要擁有數(shù)據(jù)庫的SELECT、REPLICATION SLAVE、REPLICATION CLIENT權限。給數(shù)據(jù)源添加數(shù)據(jù)庫對應權限的操作詳情可參見步驟2：創(chuàng)建賬號并配置權限。

MySQL實時同步報錯：parse.exception.PositionNotFoundException: can't find start position forxxx

同步未找到位點，請重置位點。

MySQL實時同步報錯：數(shù)據(jù)庫位點過期，請重新選擇位點，源庫可用最早位點xxx

• 重置位點：在啟動實時同步任務時，重置位點并選擇源庫可用的最早位點。

• 調整Binlog保留時間：如果數(shù)據(jù)庫位點過期，可以考慮在MySQL數(shù)據(jù)庫中調整Binlog的保留時間，例如設置為7天。

• 數(shù)據(jù)同步：如果數(shù)據(jù)已經(jīng)丟失，可以考慮重新全量同步，或者配置一個離線同步任務來手動同步丟失的數(shù)據(jù)。

實時同步Hologres報錯：permission denied for database xxx

實時同步Hologres數(shù)據(jù)時，需要在Hologres給當前操作用戶Hologres實例的admin權限（需要有創(chuàng)建schema的權限），操作詳情可參見Hologres權限模型概述。

實時同步至MaxCompute報錯：ODPS-0410051:invalid credentials-accessKeyid not found

當實時同步至MaxCompute數(shù)據(jù)源且使用臨時AK進行同步時，臨時AK超過7天會自動過期，同時，將導致任務運行失敗。平臺檢測到臨時AK導致任務失敗時會自動重啟任務，如果任務配置了該類型的監(jiān)控報警，您將會收到報警信息。

實時同步至Oracle報錯：logminer doesn't init, send HeartbeatRecord

實時同步至Oracle任務在初始化找合適的同步位點時，需要加載上一份歸檔的日志，如果歸檔日志較大，則需要加載3～5分鐘才會完成初始化init階段。