文件首頁
MySQL 9.0 參考手冊
相關文件 下載本手冊
PDF (US Ltr) - 40.0Mb
PDF (A4) - 40.1Mb
Man Pages (TGZ) - 258.2Kb
Man Pages (Zip) - 365.3Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 9.0 參考手冊  /  ...  /  複製權限檢查

19.3.3 複製權限檢查

預設情況下,MySQL 複製 (包括群組複製) 在另一個伺服器已接受的交易套用至複本或群組成員時,不會執行權限檢查。您可以建立具有適當權限的使用者帳戶,以套用通常在通道上複製的交易,並使用 CHANGE REPLICATION SOURCE TO 陳述式,將此指定為複製套用程式的 PRIVILEGE_CHECKS_USER 帳戶。然後,MySQL 會根據使用者帳戶的權限檢查每筆交易,以驗證您已授權該通道的操作。管理員也可以安全地使用該帳戶,從 mysqlbinlog 輸出套用或重新套用交易,例如,從通道上的複製錯誤中復原。

使用 PRIVILEGE_CHECKS_USER 帳戶有助於保護複製通道,防止未經授權或意外使用具權限或不需要的操作。PRIVILEGE_CHECKS_USER 帳戶在以下情況下提供額外的安全性層級

  • 您正在組織網路上的伺服器執行個體與另一個網路上的伺服器執行個體之間進行複製,例如雲端服務供應商提供的執行個體。

  • 您想要有多個內部部署或異地部署以獨立單位進行管理,而無需在所有部署上授予一個管理員帳戶權限。

  • 您想要有一個管理員帳戶,該帳戶允許管理員僅執行與複製通道及其複製的資料庫直接相關的操作,而不是在伺服器執行個體上具有廣泛的權限。

您可以在指定通道的 PRIVILEGE_CHECKS_USER 帳戶時,將以下其中一個或兩個選項新增至 CHANGE REPLICATION SOURCE TO 陳述式,以提高應用權限檢查的複製通道的安全性

  • REQUIRE_ROW_FORMAT 選項使複製通道僅接受基於列的複製事件。設定 REQUIRE_ROW_FORMAT 時,您必須在來源伺服器上使用基於列的二進制記錄 (binlog_format=ROW)。使用基於陳述式的二進制記錄時,PRIVILEGE_CHECKS_USER 帳戶可能需要一些管理員層級的權限才能成功執行交易。

  • REQUIRE_TABLE_PRIMARY_KEY_CHECK 選項使複寫通道使用其自身的原則進行主鍵檢查。設定為 ON 表示永遠需要主鍵,而設定為 OFF 表示永遠不需要主鍵。預設設定 STREAM 會使用從來源複寫的每個交易值,設定 sql_require_primary_key 系統變數的會期值。當設定 PRIVILEGE_CHECKS_USER 時,將 REQUIRE_TABLE_PRIMARY_KEY_CHECK 設定為 ONOFF 表示使用者帳戶不需要會期管理層級權限來設定受限制的會期變數,這些變數是變更 sql_require_primary_key 值所必需的。它也標準化了不同來源的複寫通道行為。

您授予 REPLICATION_APPLIER 權限,以允許使用者帳戶作為複寫應用程式執行緒的 PRIVILEGE_CHECKS_USER,並執行 mysqlbinlog 使用的內部使用 BINLOG 陳述式。PRIVILEGE_CHECKS_USER 帳戶的使用者名稱和主機名稱必須遵循第 8.2.4 節「指定帳戶名稱」中所述的語法,而且使用者不得為匿名使用者(使用者名稱為空白)或 CURRENT_USER。若要建立新的帳戶,請使用 CREATE USER。若要授予此帳戶 REPLICATION_APPLIER 權限,請使用 GRANT 陳述式。例如,若要建立使用者帳戶 priv_repl,該帳戶可以由管理員從 example.com 網域中的任何主機手動使用,並且需要加密連線,請執行下列陳述式

mysql> SET sql_log_bin = 0;
mysql> CREATE USER 'priv_repl'@'%.example.com' IDENTIFIED BY 'password' REQUIRE SSL;
mysql> GRANT REPLICATION_APPLIER ON *.* TO 'priv_repl'@'%.example.com';
mysql> SET sql_log_bin = 1;

使用 SET sql_log_bin 陳述式是為了避免將帳戶管理陳述式新增至二進制日誌並傳送至複寫通道(請參閱第 15.4.1.3 節「SET sql_log_bin 陳述式」)。

重要事項

caching_sha2_password 驗證外掛程式是新使用者的預設外掛程式(詳細資訊請參閱第 8.4.1.1 節「快取 SHA-2 可插拔驗證」)。若要使用此外掛程式驗證的使用者帳戶連線到伺服器,您必須設定第 19.3.1 節「設定複寫以使用加密連線」中所述的加密連線,或啟用不加密連線以支援使用 RSA 金鑰對交換密碼。

設定使用者帳戶後,請使用 GRANT 陳述式授予額外權限,以允許使用者帳戶進行您期望應用程式執行緒執行的資料庫變更,例如更新伺服器上特定的資料表。這些相同的權限允許管理員在需要在複寫通道上手動執行任何這些交易時使用該帳戶。如果您嘗試執行未授予適當權限的意外操作,則會禁止該操作,並且複寫應用程式執行緒會停止並顯示錯誤。第 19.3.3.1 節「複寫 PRIVILEGE_CHECKS_USER 帳戶的權限」說明該帳戶需要的其他權限。例如,若要授予 priv_repl 使用者帳戶 INSERT 權限以將資料列新增至 db1 中的 cust 資料表,請執行下列陳述式

mysql> GRANT INSERT ON db1.cust TO 'priv_repl'@'%.example.com';

您可以使用 CHANGE REPLICATION SOURCE TO 陳述式,為複寫通道指派 PRIVILEGE_CHECKS_USER 帳戶。如果複寫正在執行,請在 CHANGE REPLICATION SOURCE TO 陳述式之前執行 STOP REPLICA,並在其之後執行 START REPLICA。強烈建議在設定 PRIVILEGE_CHECKS_USER 時使用以列為基礎的二進制日誌;您可以使用該陳述式將 REQUIRE_ROW_FORMAT 設定為強制執行此操作。

當您重新啟動複寫通道時,會從那時起應用動態權限檢查。但是,靜態全域權限不會在應用程式執行緒的內容中啟用,直到您重新載入授權表為止,因為這些權限不會針對已連線的用戶端變更。若要啟動靜態權限,請執行重新整理權限操作。這可以透過執行 FLUSH PRIVILEGES 陳述式,或執行 mysqladmin flush-privilegesmysqladmin reload 命令來完成。

例如,若要在正在執行的複寫實例上的通道 channel_1 上開始進行權限檢查,請執行下列陳述式

mysql> STOP REPLICA FOR CHANNEL 'channel_1';
mysql> CHANGE REPLICATION SOURCE TO
     >    PRIVILEGE_CHECKS_USER = 'priv_repl'@'%.example.com',
     >    REQUIRE_ROW_FORMAT = 1 FOR CHANNEL 'channel_1';
mysql> FLUSH PRIVILEGES;
mysql> START REPLICA FOR CHANNEL 'channel_1';

如果您未指定通道,且不存在其他通道,則該陳述式會套用至預設通道。通道的 PRIVILEGE_CHECKS_USER 帳戶的使用者名稱和主機名稱會顯示在 Performance Schema replication_applier_configuration 資料表中,它們會正確逸出,因此可以將其直接複製到 SQL 陳述式中來執行個別交易。

如果您使用 Rewriter 外掛程式,則應授予 PRIVILEGE_CHECKS_USER 使用者帳戶 SKIP_QUERY_REWRITE 權限。這可以防止此使用者發出的陳述式被重寫。如需詳細資訊,請參閱第 7.6.4 節「重寫器查詢重寫外掛程式」

當為複寫通道設定 REQUIRE_ROW_FORMAT 時,複寫應用程式不會建立或捨棄暫存資料表,因此不會設定 pseudo_thread_id 會期系統變數。它不會執行 LOAD DATA INFILE 指令,因此不會嘗試執行檔案操作來存取或刪除與資料載入相關聯的暫存檔案(記錄為 Format_description_log_event)。它不會執行 INTVARRANDUSER_VAR 事件,這些事件是用於針對以陳述式為基礎的複寫重現用戶端的連線狀態。(例外情況是與 DDL 查詢相關聯的 USER_VAR 事件,這些事件會被執行。)它不會執行在 DML 交易中記錄的任何陳述式。如果複寫應用程式在嘗試排隊或套用交易時偵測到任何這些類型的事件,則不會套用該事件,並且複寫會停止並顯示錯誤。

無論您是否設定 PRIVILEGE_CHECKS_USER 帳戶,您都可以為複寫通道設定 REQUIRE_ROW_FORMAT。當您設定此選項時所實作的限制會提高複寫通道的安全性,即使沒有權限檢查也是如此。您也可以在使用 mysqlbinlog 時指定 --require-row-format 選項,以在 mysqlbinlog 輸出中強制執行以列為基礎的複寫事件。

安全性內容。依預設,當使用指定為 PRIVILEGE_CHECKS_USER 的使用者帳戶啟動複寫應用程式執行緒時,會使用預設角色或在 activate_all_roles_on_login 設定為 ON 時使用所有角色來建立安全性內容。

您可以使用角色將一般權限集提供給用作 PRIVILEGE_CHECKS_USER 帳戶的帳戶,如下列範例所示。在這裡,不是像先前的範例那樣將 db1.cust 資料表的 INSERT 權限直接授予使用者帳戶,而是將此權限與 REPLICATION_APPLIER 權限一起授予角色 priv_repl_role。然後,使用該角色將權限集授予兩個使用者帳戶,這兩個使用者帳戶現在都可以用作 PRIVILEGE_CHECKS_USER 帳戶

mysql> SET sql_log_bin = 0;
mysql> CREATE USER 'priv_repa'@'%.example.com'
                  IDENTIFIED BY 'password'
                  REQUIRE SSL;
mysql> CREATE USER 'priv_repb'@'%.example.com'
                  IDENTIFIED BY 'password'
                  REQUIRE SSL;
mysql> CREATE ROLE 'priv_repl_role';
mysql> GRANT REPLICATION_APPLIER TO 'priv_repl_role';
mysql> GRANT INSERT ON db1.cust TO 'priv_repl_role';
mysql> GRANT 'priv_repl_role' TO
                  'priv_repa'@'%.example.com',
                  'priv_repb'@'%.example.com';
mysql> SET DEFAULT ROLE 'priv_repl_role' TO
                  'priv_repa'@'%.example.com',
                  'priv_repb'@'%.example.com';
mysql> SET sql_log_bin = 1;

請注意,當複寫應用程式執行緒建立安全性內容時,它會檢查 PRIVILEGE_CHECKS_USER 帳戶的權限,但不會執行密碼驗證,也不會執行與帳戶管理相關的檢查,例如檢查帳戶是否已鎖定。建立的安全性內容在複寫應用程式執行緒的整個生命週期中保持不變。