用於自動增量的mysql bin日誌模式

目前我們有一個數據庫，其中STATEMENT bin日誌格式正常工作。
現在我們添加一個帶有自動增量值的新表格。
此自動增量列對業務邏輯無用。
我們已將此添加爲我們主鍵的一部分。
此處offer_expiry_time是主鍵的第一部分，因爲我們將所有查詢都作爲基於到期時間範圍的範圍查詢。用於自動增量的mysql bin日誌模式

假定我們的表看起來與此類似：

 
CREATE TABLE offer_expiry_info 
    offer_expiry_time BIGINT UNSIGNED NOT NULL null, 
    purchase_id INT UNSIGNED auto_increment, 
    PRIMARY KEY (offer_expiry_time, purchase_id), 
    KEY idx_purchase_id (purchase_id) 
)ENGINE = INNOBB;

現在，我們關注的是：

威爾語句級斌日誌格式工作這個表？（即使我們對跨越複製的自動增量列使用不同的值也可以）。基本上STATEMENT級別能夠工作嗎？
如果它起作用在啓動失敗的數據庫機器時可能發生的問題是什麼？
如果STATEMENT模式不起作用，那麼我們可以單獨使用特定的（MIXED）複製模式嗎？同一個數據庫中的其餘表可以有STATEMENT模式嗎？
這可能是一個非常愚蠢的問題，因爲我不知道如何處理複製的MySQL。是否可以指定基於查詢類型的複製模式？（對於插入查詢，行級別複製和DELETE查詢執行STATEMENT級別複製）

問題4是因爲我們基於基於範圍的刪除執行刪除，因此如果我們可以使用STATEMENT複製刪除查詢。

 
DELETE FROM order_expiry_info WHERE offer_expiry_time "LESS THAN" SOME TIME

因爲我們做批量插入，語句級別的複製會幫助我們很多。
是否有可能使自動增量列的表具有STATEMENT級別bin日誌格式？

[編輯] 此外，我們還有事務隔離級別的另一個問題。
錯誤：「收到錯誤的二進制日誌不可能消息：交易水平‘REA d-未提交’InnoDB的不是二進制日誌模式‘聲明’安全」

任何建議將非常有幫助嗎？

來源

2012-10-02 Thiyanesh

是的，這些方案可以在語句binlogs中正常工作。

如果您可以訪問日誌，您會看到在每個語句之前會記錄某些值，以確保時間戳和自動增量值等內容將得到適當保存。

我一直在使用基於聲明的複製多年，沒有任何這些方面的問題。我會建議堅持這一點，只考慮基於行或混合複製，如果出現可能需要它們的特定性能情況。

請注意，某些類型的使用情況對於基於報表的複製是不安全的，但簡單的自動增量使用不是其中之一。

來源

2012-10-02 06:24:38

感謝您的回答。我在事務隔離級別上遇到了另一個問題。「消息：InnoDB中的事務級別'REA D-COMMITTED'對於二進制日誌模式'STATEMENT'不安全」「 – Thiyanesh

由於任何特定原因您使用'READ-COMMITTED'嗎？我一直使用'REPEATABLE-READ'並且在該區域沒有問題。 –

對不起，我們實際上是使用READ-UNCOMMITTED。我們有使用場景，其中重複數據可能會在不同的請求中出現。因此我們使用READ-UNCOMMITTED模式。更改爲「READ-COMMITTED」進行測試並仍然收到相同的錯誤 – Thiyanesh

用於自動增量的mysql bin日誌模式

回答

相關問題