Debezium 源端數(shù)據(jù)庫是：MySQL

在一開始進(jìn)行數(shù)據(jù)同步的時候，任務(wù)無法運行，拋出異常。

User does not have the 'LOCK TABLES' privilege required to obtain a consistent snapshot by preventing concurrent writes to tables.

<user_name>權(quán)限如下：

grant select, reload, show databases, replication slave, replication client on *.* to 'testuser'@'%'; grant create,select, insert, update, delete on testdb.* to testuser@'%'; grant select on mysql.db to testuser@'%'; flush privileges;

所賦權(quán)限有RELOAD，包含了'LOCK TABLES' 的鎖表權(quán)限，還是報錯。

原因如下：

當(dāng)啟動MySQL CDC源時，它將獲取一個全局讀取鎖（FLUSH TABLES WITH READ LOCK），該鎖將阻止其他數(shù)據(jù)庫的寫入，然后讀取當(dāng)前binlog位置以及數(shù)據(jù)庫和表的schema，之后將釋放全局讀取鎖。然后它掃描數(shù)據(jù)庫表并從先前記錄的位置讀取binlog，debezium將定期執(zhí)行checkpoints以記錄binlog位置。如果發(fā)生故障，作業(yè)將重新啟動并從checkpoint完成的binlog位置恢復(fù)，因此它保證了僅一次的語義。

所以，檢查權(quán)限沒有問題之后，出現(xiàn)的原因是：正在向表里寫入數(shù)據(jù)，無法鎖表導(dǎo)致的。

全局讀取鎖 在讀取binlog位置和schema期間保持。這可能需要幾秒鐘，具體取決于表的數(shù)量。全局讀取鎖定會阻止寫入，因此它仍然可能影響在線業(yè)務(wù)。如果要跳過讀取鎖，并且可以容忍至少一次語義，則可以添加'debezium.snapshot.locking.mode' = 'none'選項以跳過鎖。

總結(jié)

以上是生活随笔為你收集整理的User does not have the ‘LOCK TABLES‘ privilege required to obtain a consistent snapshot by preventin的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。