預設情況下,當已由另一個伺服器接受的交易套用在複本或群組成員上時,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
設定為ON
或OFF
表示使用者帳戶不需要工作階段管理等級的權限來設定受限制的工作階段變數,這些變數是變更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.2 節「快取 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 作業。這可以使用發出 FLUSH PRIVILEGES
陳述式或執行 mysqladmin flush-privileges
或 mysqladmin 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
帳戶的使用者名稱和主機名稱會顯示在效能結構描述 replication_applier_configuration
表格中,這些名稱經過適當跳脫,因此可以直接複製到 SQL 陳述式中,以執行個別的交易。
如果您使用的是 Rewriter
外掛程式,您應該授與 PRIVILEGE_CHECKS_USER
使用者帳戶 SKIP_QUERY_REWRITE
權限。這可防止此使用者發出的陳述式遭到重寫。如需詳細資訊,請參閱 第 7.6.4 節「Rewriter 查詢重寫外掛程式」。
當為複製通道設定 REQUIRE_ROW_FORMAT
時,複製套用程式不會建立或捨棄暫存表格,因此不會設定 pseudo_thread_id
工作階段系統變數。它不會執行 LOAD DATA INFILE
指示,因此不會嘗試檔案操作以存取或刪除與資料載入相關聯的暫存檔案 (記錄為 Format_description_log_event
)。它不會執行 INTVAR
、RAND
和 USER_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
帳戶的權限,但不會執行密碼驗證,也不會執行與帳戶管理相關的檢查,例如檢查帳戶是否已鎖定。建立的安全性內容在複製套用程式執行緒的生命週期內保持不變。