如何判斷數據遷移任務可以停止

通常，在業務割接完成后，為了防止源數據庫的操作繼續同步到目標數據庫，造成數據覆蓋問題，您可選擇結束遷移任務。結束之前您需要確認完成以下幾點：

1. 請您確認至少在業務低峰期有過一次完整的數據對比。
2. 完成業務割接。

a. 先中斷業務（如果業務負載非常輕，也可以嘗試不中斷業務）。

b. 在源數據庫端執行如下語句（此處以MySQL為例），并觀察在1-5分鐘內若無任何新會話執行SQL ，則可認為業務已經完全停止。

show processlist;

上述語句查詢到的進程列表中，包括DRS遷移實例的連接，您需要確認除DRS遷移實例的連接外無任何新會話執行SQL，即可認為業務已經完全停止。

c. 實時同步時延為0，并穩定保持一段時間；同時，您可以使用數據級對比功能，進行割接前的最后一次數據級對比，耗時可參考之前的對比記錄。

n 如果時間允許，則選擇全部對比。

n 如果時間不允許，則推薦對比活躍表，關鍵業務表，第二步對比多次存在差異的表等。

d. 確定系統割接時機，業務系統指向目標數據庫，業務對外恢復使用。

3. 結束遷移任務，該操作僅刪除了遷移實例，遷移任務仍顯示在任務列表中，您可以進行查看或刪除。

MySQL遷移中Definer強制轉化后如何維持原業務用戶權限體系

Definer的使用主要應用在視圖、存儲過程、觸發器、事件等對象里，Definer并不會限制對象被調用的權限，但會限制對象訪問數據庫的權限。本場景下，用戶在MySQL遷移過程中選擇了“所有Definer遷移到該用戶下”，則源庫用戶體系下其他用戶賬號在完成用戶遷移后，如果用戶遷移和權限授權都執行成功，則無需授權便可繼續使用原業務（使用DRS用戶遷移功能可以實現用戶、權限、密碼遷移），否則如果想在原來的用戶權限體系下延用原業務，則需要進行授權后才具有Definer相關數據庫對象的訪問使用權限，從而保證原業務正常。

本章節主要介紹如何通過數據庫命令行對用戶賬號進行授權的方法。

步驟 1 確保新用戶（Definer統一使用指定賬號）具備足夠的權限執行視圖、存儲過程等相關SQL。

步驟 2通過MySQL官方客戶端或者其它工具登錄目標數據庫。

步驟 3 通過如下命令查看需要授權的用戶user當前權限詳情。

show grants for 'user'@'host';

步驟 4 為了保證原業務不報錯，使用如下命令給用戶user授予涉及的數據庫對象缺失的操作權限。

grant select,insert,update,delete on db_name.* to 'user'@'host';

一般情況下，訪問數據庫的權限包括：SELECT、CREATE、DROP、DELETE、INSERT、UPDATE、INDEX、EVENT、CREATE VIEW、CREATE ROUTINE、TRIGGER、EXECUTE。您需要根據具體的數據庫對象查看缺少哪些權限，再進行授權操作。

對于存儲過程和函數，必須保證用戶user對其有擁有EXECUTE權限，授權SQL命令如下：

grant execute on db_name.function_name to 'user'@'host';

步驟 5 使用授權后的用戶賬號訪問目標庫對象，無異常報錯表示授權成功。需要注意：在java項目工程中調用存儲過程、函數如果出現 Java.sql.SQLException: User does not have access to metadata required to determine stored procedure parameter types. If rights can not be granted, configure connection with "noAccessToProcedureBodies=true" to have driver generate parameters that represent INOUT strings irregardless of actual parametertypes，則需要單獨執行用戶user對mysql.proc庫的授權：

grant select on mysql.proc to 'user'@'host';

MySQL存儲過程遷移上云后遇到調用權限的問題，如何解決

MySQL存儲過程遷移上云后，可能會因為權限問題導致調用存儲過程或函數出錯。

針對該情況，不同的Definer策略有不同的處理方法。本章節主要以user1為示例，介紹兩種遷移Definer的策略下的處理方法。

策略一

在測試連接頁面的目標庫信息中填寫數據庫用戶名user1，所有Definer遷移到該用戶下選“是”。

這種策略下，源庫所有存儲過程和方法的Definer遷移到目標庫后賬號都會自動修改為user1，host改為% 。若在目標庫上出現調用存儲過程失敗的情況，可執行如下操作：

步驟 1 使用uesr1賬號登錄到目標庫RDS for MySQL實例。

步驟 2 如果需要使用其他賬號調用存儲過程，則該賬號需要具有execute權限。

步驟 3 通過如下語句，使用user1授予其他賬號執行存儲過程的權限。

其中user表示需要調用存儲過程的其他賬號：

GRANT EXECUTE ON db.* TO user;

步驟 4 如果需要通過Java調用存儲過程，則需要通過如下語句，使用user1授予其他賬號查詢mysql.proc表的權限。

授權語句可參考如下語句，user表示需要調用存儲過程的賬號：

GRANT SELECT ON mysql.proc TO 'user'@'%';

策略二

在測試連接頁面的目標庫信息中填寫數據庫用戶名user1，所有Definer遷移到該用戶下選“否”。

這種策略下，源庫所有存儲過程和方法的Definer遷移到目標庫后賬號和host保持不變，選擇此選項，需要配合2.3.5.1** **遷移用戶功能，將源數據庫的用戶全部遷移，這樣才能保持源數據庫的權限體系完全不變。

如果您未選擇用戶權限遷移或者用戶權限遷移時存在不支持遷移的賬號，建議選擇[策略一]( " ")來處理。

如何確保業務數據庫的全部業務已經停止

業務切換時可通過如下方法確保業務數據庫的全部業務已經停止：

步驟 1 在源數據庫端執行如下語句，查看當前是否還存在有業務連接。

show processlist;

圖 查看是否存在業務連接

步驟 2 可選: ****如果源數據庫有業務連接，則通過結果中Host列的值來查找對應的業務進程并將其停止。

步驟 3 在源庫執行如下語句，查看binlog位置并記錄該值（file列取值:position列取值 ），此處將該值記為ckpt1。

show master status;

圖 查看binlog位置

步驟 4 等待30s以上，在源庫執行如下語句，查看binlog位置并記錄該值（file列取值:position列取值 ），此處將該值記為ckpt2。ckpt1=ckpt2時，表示源數據庫業務已基本停寫。

show master status;

使用定時啟動任務失敗，遷移日志提示can not get agency token

使用定時啟動任務功能時，如果使用的是子賬號，需要使用“賬戶委托”，否則任務啟動失敗，遷移日志報：can not get agency token。

解決方案

目前針對該情況，分別提供如下解決方案：

方法一：使用主賬號重新創建任務，啟動方式選擇“定時啟動”。

方法二：使用主賬號在子賬號所在的用戶組添加Security Administrator權限后，重新創建任務，啟動方式選擇“定時啟動”。

方法三：重新創建任務，啟動方式選擇“立即啟動”。

RDS for MySQL不支持MyISAM引擎表，遷移時MyISAM如何處理

基于以下原因，RDS for MySQL目前不支持MyISAM引擎。

MyISAM引擎表不支持事務，僅支持表級別鎖，導致讀寫操作相互沖突。

MyISAM對數據完整性的保護存在缺陷，且這些缺陷會導致數據庫數據的損壞甚至丟失。

MyISAM在出現數據損害情況下，很多都需要手動修復，無法通過產品服務提供的恢復功能進行數據恢復。

MyISAM向InnoDB的遷移透明，大多數情況不需要改動建表的代碼，云數據庫自動轉換InnoDB即可完成遷移。

DRS在遷移過程中，會自動將MyISAM轉換為InnoDB。針對MyISAM引擎表不支持事務這一特點，為了確保MyISAM表的數據一致性， DRS會借助主鍵來實現最終數據的一致。如果需要遷移沒有主鍵的MyISAM表，建議選擇無業務期啟動遷移任務，以確保數據的一致性。

低版本遷移至MySQL 8.0，應該注意哪些問題

MySQL 8.0較MySQL 5.7增加了一些新的特性，并在性能表現上存在差異。遷移前，需要做兼容性分析并給出解決方案。可以從兼容性、系統變量等方面考慮。

兼容性分析：

針對MySQL8.0社區版與MySQL5.7社區版進行分析，包括以下兩方面：

a. 不影響遷移，但使用方法出現差異。

兼容性	檢查項	作用	狀態	解決方案
數據類型或函數	ENCODE()函數	加密	移除	AES_ENCRYPT()函數代替
DECODE()函數	解密	移除	AES_DECRYPT()函數代替
ENCRYPT()函數	加密	移除	SHA2()函數代替
DES_ENCRYPT()函數	加密	移除	AES_ENCRYPT()函數代替
DES_DECRYPT()函數	解密	移除	AES_DECRYPT()函數代替
JSON_APPEND()函數	增加json元素	移除	JSON_ARRAY_APPEND()函數代替
PASSWORD()函數	修改用戶密碼	移除	ALTER USER user IDENTIFIED BY 'auth_string';
JSON_MERGE()函數	將多個json合并為一個	廢棄	JSON_MERGE_PERSERVE()函數代替
SQL MODE	NO_AUTO_CREATE_USER、DB2, MAXDB, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS	-	移除	-
外鍵約束長度	外鍵約束名稱不能超過64個字符	-	-	SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME IN (SELECT LEFT(SUBSTR(ID,INSTR(ID,'/')+1), INSTR(SUBSTR(ID,INSTR(ID,'/')+1),'ibfk')-1) FROM INFORMATION_SCHEMA.INNODB_SYS_FOREIGN WHERE LENGTH(SUBSTR(ID,INSTR(ID,'/')+1))>64);使用ALTER TABLE調整長度
features	GRANT創建用戶	-	移除	CREATE USER
GRANT修改用戶信息	-	移除	ALTER USER
IDENTIFIED BY PASSWORD 'auth_string'	設置密碼	移除	IDENTIFIED WITH auth_plugin AS 'auth_string'
SQL語句中的\N	NULL	移除	NULL代替
PROCEDURE ANALYSE()語法	對MySQL字段值進行統計分析后給出建議的字段類型	移除	-
空間函數	-	-	-
mysql_install_db	初始化	移除	mysqld --initialize或--initialize-insecure

b. 影響遷移，需要提前做檢查。

兼容性	檢查項	作用	狀態	解決方案	原始用法
保留關鍵字	cume_dist、dense_rank、empty、except、first_value、grouping、groups、json_table、lag、last_value、lateral、lead、nth_value、ntile、of、over、percent_rank、rank、recursive、row_number、system、window	-	新增	SET sql_mode = 'ANSI_QUOTES'	名稱：數據庫、表、索引、列、alias、view、存儲過程、分區、表空間
字符集	UTF8MB3	-	廢棄	使用UTF8MB4代替	-
分區表	不得出現不支持本地分區的存儲引擎的分區表	-	移除	SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';可按照下述兩種方式解決：（1）ALTER TABLE table_name ENGINE=INNODB;（2）ALTER TABLE table_name REMOVE PARTITIONING;	不支持MyISAM
語法	group by … asc/desc	升序/降序	移除	使用order by子句代替	view、function等
名稱長度	view的列名稱不能超過64個字符	-	-	alter處理	最多255個字符
enum或set元素的總長度不能超過255個字符	-	-	用戶處理	最大64K
大小寫	lower_case_table_names	MySQL設置字母大小寫是否敏感	-	升級過程中，如果設置該參數為1，則必須確保schema和table名稱必須是小寫的SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME != LOWER(TABLE_NAME) AND TABLE_TYPE = 'BASE TABLE';SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME != LOWER(SCHEMA_NAME);	-
觸發器	是否有空定義或者無效的創建上下文	-	-	show triggers查看，檢測character_set_client、 collation_connection、Database Collation屬性	-

系統變量默認值變更

針對社區版MySQL5.7與8.0版本的默認值作對比，默認值不影響遷移，但對遷移后的業務會產生影響。

序號	parameter/option	community	作用	備注
原默認值	新默認值
Server
1	character_set_server	latin1	utf8mb4	-
2	collation_server	latin1_swedish_ci	utf8mb4_0900_ai_ci	-
3	explicit_defaults_for_timestamp	OFF	ON	更新某一行時是否更新timestamp列
4	optimizer_trace_max_mem_size	16KB	1MB	-
5	validate_password_check_user_name	OFF	ON	-
6	back_log	-1 (autosize) changed from : back_log = 50 + (max_connections / 5)	-1 (autosize) changed to : back_log = max_connections	在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。
7	max_allowed_packet	4194304 (4MB)	67108864 (64MB)	限制Server接受的數據包大小
8	max_error_count	64	1024	控制顯示告警的個數
9	event_scheduler	OFF	ON	-
10	table_open_cache	2000	4000	-
11	log_error_verbosity	3 (Notes)	2 (Warning)	-
INNODB
1	innodb_undo_tablespaces	0	2	-
2	innodb_undo_log_truncate	OFF	ON	-
3	innodb_flush_method	NULL	fsync (Unix),unbuffered (Windows)	控制innodb數據文件及redo log的打開、刷寫模式
4	innodb_autoinc_lock_mode	1 (consecutive)	2 (interleaved)	控制著在向有auto_increment 列的表插入數據時，相關鎖的行為；
5	innodb_flush_neighbors	1 (enable)	0 (disable)	從緩沖池刷新頁面是否也刷新相同范圍內的其他臟頁。
6	innodb_max_dirty_pages_pct_lwm	0 (%)	10 (%)	影響innodb刷新臟頁行為
7	innodb_max_dirty_pages_pct	75 (%)	90 (%)	影響innodb刷新臟頁行為
PERFORMANCE SCHEMA	整體是不是開的	-	-	-
REPLICATION
1	log_bin	OFF	ON	-
2	server_id	0	1	-
3	log-slave-updates	OFF	ON	-
4	expire_log_days	0	30	-
5	master-info-repository	FILE	TABLE	-
6	relay-log-info-repository	FILE	TABLE	-
7	transaction-write-set-extraction	OFF	XXHASH64	-
8	slave_rows_search_algorithms	INDEX_SCAN, TABLE_SCAN	INDEX_SCAN, HASH_SCAN	-

移除系統變量

針對社區版MySQL 5.7與8.0進行分析，移除系統變量不影響遷移。

移除變量
innodb_locks_unsafe_for_binlog
log_builtin_as_identified_by_password
old_passwords
query_cache_limit
query_cache_min_res_unit
query_cache_size
query_cache_type
query_cache_wlock_invalidate
ndb_cache_check_time
ignore_db_dirs
tx_isolation
tx_read_only
sync_frm
secure_auth
multi_range_count
log_error_verbosity
sql_log_bin
metadata_locks_cache_size
metadata_locks_hash_instances
date_format
datetime_format
time_format
max_tmp_tables
ignore_builtin_innodb
innodb_support_xa
innodb_undo_logs
innodb_undo_tablespaces
internal_tmp_disk_storage_engine

MongoDB數據庫遷移過程中，源數據庫出現內存溢出（OOM）是什么原因

場景描述

在進行MongoDB數據庫遷移的過程中，出現源數據庫內存溢出（OOM），導致源數據庫不可用，遷移失敗。

問題分析

出現上述內存溢出可能存在如下原因：

源數據庫的mongod服務單獨部署在一臺機器上，如果這種情況下在遷移過程中出現內存溢出，一般就是因為在遷移過程中源庫在執行會大量消耗內存的操作，比如：創建索引，排序查詢等。

源數據庫的mongod服務和其他服務同時部署在一臺機器上，而且沒有設置cacheSizeGB的大小，這種情況下，如果因為其他服務消耗掉內存導致不能給wiredTiger引擎保證的內存，則會出現內存溢出的情況。

一般默認情況下，mongod的wiredTiger引擎可以使用整個機器內存減一的50%（3.2的版本）或者60%（3.4以后的版本）。

解決方案

如果mongod服務是單獨部署在一臺機器上，則在遷移過程中最好不要執行會大量消耗內存的操作，比如：創建索引，排序查詢等。

如果mongod服務和其他服務共同部署在一臺機器上，則建議給mongod的wiredTiger引擎加上cacheSizeGB的參數，設置的值為機器最小空閑內存的一半，保證所有服務在高峰期所使用的內存不會超過分配給wiredTiger引擎的內存。

如何關閉集合均衡器Balancer

使用DRS服務進行MongoDB數據庫分片集群到分片集群的遷移，必須關閉要遷移集合的均衡器Balancer。

遷移結束后請開啟Balancer，因為在遷移期間關閉了Balancer，源數據庫的不同shard可能產生了不等量的塊（chunk），在Balancer開啟之后集群shard之間的塊（chunk）移動會暫時影響源數據庫的性能。

關閉Balancer的步驟

步驟 1通過Mongo Shell 登錄數據庫。

步驟 2 在mongos節點命令窗口中，使用如下命令，切換至config數據庫。

use config

步驟 3 執行如下命令，判斷是否可以關閉Balancer。

while( sh.isBalancerRunning() ) {

print("waiting...");

sleep(1000);** **

}

如果返回結果是waiting，則表示當前Balancer正在執行塊（chunk）遷移，此時不能執行關閉Balancer的命令，否則可能引起數據不一致。

圖 查看輸出結果

如果返回結果是空，則表示當前Balancer沒有在進行塊（chunk）遷移，此時可以執行下一步的關閉Balancer的命令。

步驟 4 關閉Balancer。

如果是整個實例的遷移，則執行如下命令，可以關閉整個實例的Balancer。

sh.stopBalancer()

如果要關閉待遷移且已經開啟了分片的集合的Balancer，則執行如下命令：

sh.disableBalancing("database.collection")

其中database.collection表示要關閉的集合的namespace。

如何批量導出、導入事件（event）和觸發器（trigger）

在進行MySQL到MySQL的遷移時，若任務結束后發現遷移日志中提示遷移事件和觸發器失敗，可手動遷移。

本小節主要介紹批量導出導入事件和觸發器的具體操作。

步驟 5 從源庫批量導出觸發器。

4. 在源庫執行以下語句，獲取TRIGGER_SCHEMA和TRIGGER_NAME。

SELECT TRIGGER_SCHEMA,TRIGGER_NAME FROM INFORMATION_SCHEMA.TRIGGERS WHERE TRIGGER_SCHEMA in ('DB1','DB2','DB3') order by TRIGGER_NAME;

上述語句中，DB1，DB2，DB3分別表示從源庫待遷移到目標庫的數據庫。

5. 在源庫執行如下語句，從字段SQL Original Statement中獲取源庫創建觸發器的語句。

SHOW CREATE TRIGGER TRIGGER_SCHEMA.TRIGGER_NAME \G;

上述語句中，TRIGGER_SCHEMA.TRIGGER_NAME填寫的為[步驟 1.1 ]( " ")中查詢到的TRIGGER_SCHEMA和TRIGGER_NAME具體值。

步驟 6 從源庫批量導出事件。

6. 在源庫執行以下語句，獲取EVENT_SCHEMA和EVENT_NAME。

SELECT EVENT_SCHEMA,EVENT_NAME FROM INFORMATION_SCHEMA.EVENTS WHERE EVENT_SCHEMA in ('DB1','DB2','DB3') order by EVENT_NAME;

上述語句中，DB1，DB2，DB3分別表示從源庫待遷移到目標庫的數據庫。

7. 在源庫執行如下語句，從字段SQL Original Statement中獲取源庫創建事件的語句。

SHOW CREATE EVENT EVENT_SCHEMA.EVENT_NAME \G;

上述語句中，EVENT_SCHEMA.EVENT_NAME填寫的為[步驟 2.1 ]( " ")中查詢到的EVENT_SCHEMA和EVENT_NAME具體值。

步驟 7 導入觸發器和事件。

在目標庫重新執行從源庫導出的創建觸發器和創建事件語句。

源庫參數lower_case_table_names=1時，為什么不允許遷移包含大寫字母的庫或者表

場景描述

當源庫參數lower_case_table_names=1時，無法遷移包含大寫字母的庫或者表。

問題分析

當源庫的lower_case_table_names 參數值為1時，MySQL會將庫名或者表名轉換成小寫再進行查找。若存在以大寫字母形式創建的庫或者表，那么在lower_case_table_names參數值為1的情況下，MySQL將無法找到這個庫或表，報告查詢失敗。也就是說，若lower_case_table_names的參數值為1時，大寫字母的庫或表很可能是不可訪問的。

解決方案

目前針對該情況，分別提供如下解決方案：

方法一

修改源庫lower_case_table_names的參數值為0 (即大小寫敏感)，并且保證源庫與目標庫的該參數值一致。

方法二

若無法永久修改lower_case_table_names，可臨時將源庫lower_case_table_names修改為0，然后執行如下操作。

對于表，可以使用如下語句將表名轉換為小寫：

alter table BigTab rename to bigtab

對于庫，則需要導出后，修改庫名為小寫，再進行導入。

修改庫名或表名之后，需要維護權限的一致性，以免影響應用訪問。

方法三

對象選擇時不遷移該庫或者該表。

分片集群MongoDB遷移前清除孤兒文檔

什么是孤兒文檔

MongoDB負載均衡器（Balancer）會根據集合的分片鍵(Shard key)均衡數據。Balancer的工作原理是：需要Balancer的數據塊（Chunk）先復制到目標Shard，成功后再刪除原Shard上的Chunk，來完成一次Chunk遷移，通過多次Chunk遷移來實現均衡。在Chunk遷移時，如果發生網絡閃斷等不可預知的場景，完成了復制但沒有完成刪除，那么對同一條文檔會同時存在于兩個Shard上。因為Chunk遷移在MongoDB上是感知的，config會更新這條文檔應該在哪個Shard上，那么另一個Shard上的文檔會存在但不會被感知，后續的update、delete操作都不會作用于這個錯誤的Shard上的文檔，那么這條文檔被稱為孤兒文檔（Orphaned Document）。

遷移影響

DRS在遷移集群時，會從Shard上抽取全量數據。正常文檔和孤兒文檔在不同的Shard上，DRS不會感知，都會遷移到目標庫。DRS針對MongoDB遷移的沖突策略為忽略，因此最終目標庫上的文檔取決于哪個文檔先被遷過去，會造成數據內容或行數不一致。

操作步驟

步驟 1 聯系技術支持，獲取用于清除孤兒文檔的cleanupOrphaned腳本文件，然后解壓。

步驟 2 修改cleanupOrphaned.js腳本文件，將test替換為待清理孤兒文檔的數據庫名。

步驟 3 執行以下命令，清理Shard節點下指定的數據庫中所有集合的孤兒文檔。

mongo --host ShardIP ** --port** Primaryport --authenticationDatabase database -u username -p passowrd cleanupOrphaned.js

ShardIP：Shard節點的IP地址。

Primaryport：Shard節點中的Primary節點的服務端口。

database：鑒權數據庫名，即數據庫賬號所屬的數據庫。

username：登錄數據庫的賬號。

passowrd：登錄數據庫的密碼。

如果您有多個數據庫，您需要重復執行步驟[步驟 2 ]( " ")和步驟[步驟 3 ]( " ")，分別為每個數據庫的每個Shard節點清理孤立文檔。