mysql只读模式下数据迁移,保证数据一致性

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介:

   

   在MySQL数据库中,在进行数据迁移从库只读状态设置时,都会涉及到只读状态和Master-slave的设置和关系。


       经过实际测试,对于MySQL单实例数据库和master库,如果需要设置为只读状态,需要进行如下操作和设置:
      

一般单实例情况下将MySQL设置为只读状态的命令:

1
2
3
4
5
# mysql -uroot -p
mysql> show  global  variables  like  "%read_only%" ;
mysql>flush tables  with  read  lock;
mysql> set  global  read_only=1;
mysql> show  global  variables  like  "%read_only%" ;


将MySQL从只读设置为读写状态的命令:

1
2
mysql> unlock tables;
mysql>   set  global  read_only=0;

      对于需要保证master-slave主从同步的salve库,如果要设置为只读状态,需要执行的命令为:
mysql> set global read_only=1;   打开只读开关


     将salve库从只读状态变为读写状态,需要执行的命令是:
mysql> set global read_only=0;   打开读写开关


     对于数据库读写状态,主要靠 “read_only”全局参数来设定;

     默认情况下,数据库是用于读写操作的,所以read_only参数也是0或faluse状态,这时候不论是本地用户还是远程访问数据库的用户,都可以进行读写操作;

      如需设置为只读状态,将该read_only参数设置为1或TRUE状态,但设置 read_only=1 状态有两个需要注意的地方:
      1.read_only=1只读模式,不会影响slave同步复制的功能,所以在MySQL slave库中设定了read_only=1后,通过 show slave status\G 命令查看salve状态,可以看到salve仍然会读取master上的日志,并且在slave库中应用日志,保证主从数据库同步一致;
      2.read_only=1只读模式,可以限定普通用户进行数据修改的操作,但不会限定具有super权限的用户的数据修改操作;在MySQL中设置read_only=1后,普通的应用用户进行insert、update、delete等会产生数据变化的DML操作时,都会报出数据库处于只读模式不能发生数据变化的错误,但具有super权限的用户,例如在本地或远程通过root用户登录到数据库,还是可以进行数据变化的DML操作;


      为了确保所有用户,包括具有super权限的用户也不能进行读写操作,就需要执行给所有的表加读锁的命令 “flush tables with read lock;”,这样使用具有super权限的用户登录数据库,想要发生数据变化的操作时,也会提示表被锁定不能修改的报错。


        这样通过 设置“read_only=1”和“flush tables with read lock;”两条命令,就可以确保数据库处于只读模式,不会发生任何数据改变,在MySQL进行数据库迁移时,限定master主库不能有任何数据变化,就可以通过这种方式来设定。


       但同时由于加表锁的命令对数据库表限定非常严格,如果再slave从库上执行这个命令后,slave库可以从master读取binlog日志,但不能够应用日志,slave库不能发生数据改变,当然也不能够实现主从同步了,这时如果使用 “unlock tables;”解除全局的表读锁,slave就会应用从master读取到的binlog日志,继续保证主从库数据库一致同步。

       为了保证主从同步可以一直进行,在slave库上要保证具有super权限的root等用户只能在本地登录,不会发生数据变化,其他远程连接的应用用户只按需分配为select,insert,update,delete等权限,保证没有super权限,则只需要将salve设定“read_only=1”模式,即可保证主从同步,又可以实现从库只读。


       相对的,设定“read_only=1”只读模式开启的解锁命令为设定“read_only=0”;设定全局锁“flush tables with read lock;”,对应的解锁模式命令为:“unlock tables;”.
 

      当然设定了read_only=1后,所有的select查询操作都是可以正常进行的。




实验一:设置了read_only=1后,远程业务用户进行数据库修改会提示ERROR 1290错误:


 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
  copy
(test01@172.32.1.200) [data03]> show tables;  
+ ------------------+  
| Tables_in_data03 |  
+ ------------------+  
| t01              |  
| t02              |  
user              |  
+ ------------------+  
rows  in  set  (0.00 sec)  
   
(test01@172.32.1.200) [data03]>   
(test01@172.32.1.200) [data03]>   
(test01@172.32.1.200) [data03]> show  global  variables  like  "%read_only%" ;  
+ ------------------+-------+  
| Variable_name    | Value |  
+ ------------------+-------+  
| innodb_read_only |  OFF    |  
| read_only        |  ON     |  
| tx_read_only     |  OFF    |  
+ ------------------+-------+  
rows  in  set  (0.00 sec)  
   
(test01@172.32.1.200) [data03]>   
(test01@172.32.1.200) [data03]>   
(test01@172.32.1.200) [data03]>  delete  from  t01  where  id1=3;  
<span style= "color:#ff0000;" >ERROR 1290 (HY000): The MySQL server  is  running  with  the  --read-only option so it cannot execute this statement</span>  
(test01@172.32.1.200) [data03]>  update  t01  set  id1=id1+30  where  id1=3;  
ERROR 1290 (HY000): The MySQL server  is  running  with  the  --read-only option so it cannot execute this statement  
(test01@172.32.1.200) [data03]>  insert  into  t01(id1,a1,b1)  values (9,9,9);  
ERROR 1290 (HY000): The MySQL server  is  running  with  the  --read-only option so it cannot execute this statement  
(test01@172.32.1.200) [data03]>   
(test01@172.32.1.200) [data03]>  select  from  t01;  
+ -----+------+------+  
| id1 | a1   | b1   |  
+ -----+------+------+  
|   1 |    1 |    1 |  
|   2 |    2 |    2 |  
|   4 |    4 |    4 |  
|   5 |    5 |    5 |  
|   6 |    6 |    6 |  
+ -----+------+------+  
rows  in  set  (0.00 sec)  
   
(test01@172.32.1.200) [data03]>


  •  




实验二:设定了全局读写后,具有super权限的用户进行数据修改后,也会提示错误ERROR 1223:



 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
view  plain copy
mysql> use data03;  
Reading  table  information  for  completion  of  table  and  column  names  
You can turn  off  this feature  to  get a quicker startup  with  -A  
   
Database  changed  
mysql> show tables;  
+ ------------------+  
| Tables_in_data03 |  
+ ------------------+  
| t01              |  
| t02              |  
user              |  
+ ------------------+  
rows  in  set  (0.00 sec)  
   
mysql>  select  from  t01;  
+ -----+------+------+  
| id1 | a1   | b1   |  
+ -----+------+------+  
|   1 |    1 |    1 |  
|   2 |    2 |    2 |  
|   4 |    4 |    4 |  
|   5 |    5 |    5 |  
|   6 |    6 |    6 |  
+ -----+------+------+  
rows  in  set  (0.00 sec)  
   
mysql>   
mysql>  show  global  variables  like  "%read_only%" ;  
+ ------------------+-------+  
| Variable_name    | Value |  
+ ------------------+-------+  
| innodb_read_only |  OFF    |  
| read_only        |  ON     |  
| tx_read_only     |  OFF    |  
+ ------------------+-------+  
rows  in  set  (0.00 sec)  
   
mysql>   
mysql>   
mysql>  insert  into  t01(id1,a1,b1)  values (8,8,8);         
Query OK, 1 row affected (0.00 sec)  
   
mysql>  update  t01  set  a1=a1+10  where  id1=2;  
Query OK, 1 row affected (0.00 sec)  
Rows  matched: 1  Changed: 1  Warnings: 0  
   
mysql>  delete  from  t01  where  id1=4;  
Query OK, 1 row affected (0.00 sec)  
   
mysql>  select  from  t01;  
+ -----+------+------+  
| id1 | a1   | b1   |  
+ -----+------+------+  
|   1 |    1 |    1 |  
|   2 |   12 |    2 |  
|   5 |    5 |    5 |  
|   6 |    6 |    6 |  
|   8 |    8 |    8 |  
+ -----+------+------+  
rows  in  set  (0.00 sec)  
   
mysql>   
mysql> flush tables  with  read  lock;  
Query OK, 0  rows  affected (0.00 sec)  
   
mysql>   
mysql>  insert  into  t01(id1,a1,b1)  values (9,9,9);  
<span style= "color:#ff0000;" >ERROR 1223 (HY000): Can 't execute the query because you have a conflicting read lock</span>  
mysql>   
mysql> update t01 set a1=a1+10 where id1=5;  
ERROR 1223 (HY000): Can' execute  the query because you have a conflicting  read  lock  
mysql>   
mysql>  delete  from  t01  where  id1=5;  
ERROR 1223 (HY000): Can't  execute  the query because you have a conflicting  read  lock  
mysql>   
mysql>


实验三:MySQL从库设定read_only=1后主从同步正常,设定表读锁后,不能同步,解除读锁后,主从同步恢复。



  copy

  1. mysql>   

  2. mysql> show databases;  

  3. +--------------------+  

  4. | Database           |  

  5. +--------------------+  

  6. | information_schema |  

  7. | bitvc              |  

  8. | data03             |  

  9. | ga                 |  

  10. | jiradb             |  

  11. | meibi              |  

  12. | meibi02            |  

  13. | mysql              |  

  14. | performance_schema |  

  15. | sbtest             |  

  16. +--------------------+  

  17. 10 rows in set (0.00 sec)  

  18.   

  19. mysql>   

  20. mysql>   

  21. mysql>   

  22. mysql>  show global variables like "%read_only%";  

  23. +------------------+-------+  

  24. | Variable_name    | Value |  

  25. +------------------+-------+  

  26. | innodb_read_only | OFF   |  

  27. | read_only        | ON    |  

  28. | tx_read_only     | OFF   |  

  29. +------------------+-------+  

  30. 3 rows in set (0.00 sec)  

  31.   

  32. mysql>   

  33. mysql> show slave status\G  

  34. *************************** 1. row ***************************  

  35.                Slave_IO_State: Waiting for master to send event  

  36.                   Master_Host: 172.32.1.200  

  37.                   Master_User: repl  

  38.                   Master_Port: 3307  

  39.                 Connect_Retry: 60  

  40.               Master_Log_File: mysql-bin.000009  

  41.           Read_Master_Log_Pos: 5853  

  42.                Relay_Log_File: huobiDBtest-relay-bin.000002  

  43.                 Relay_Log_Pos: 6016  

  44.         Relay_Master_Log_File: mysql-bin.000009  

  45.              Slave_IO_Running: Yes  

  46.             Slave_SQL_Running: Yes  

  47.               Replicate_Do_DB:   

  48.           Replicate_Ignore_DB:   

  49.            Replicate_Do_Table:   

  50.        Replicate_Ignore_Table:   

  51.       Replicate_Wild_Do_Table:   

    1.   Replicate_Wild_Ignore_Table:   


  52.                    Last_Errno: 0  

  53.                    Last_Error:   

  54.                  Skip_Counter: 0  

  55.           Exec_Master_Log_Pos: 5853  

  56.               Relay_Log_Space: 6195  

  57.               Until_Condition: None  

  58.                Until_Log_File:   

  59.                 Until_Log_Pos: 0  

  60.            Master_SSL_Allowed: No  

  61.            Master_SSL_CA_File:   

  62.            Master_SSL_CA_Path:   

  63.               Master_SSL_Cert:   

  64.             Master_SSL_Cipher:   

  65.                Master_SSL_Key:   

  66.         Seconds_Behind_Master: 0  

  67. Master_SSL_Verify_Server_Cert: No  

  68.                 Last_IO_Errno: 0  

  69.                 Last_IO_Error:   

  70.                Last_SQL_Errno: 0  

  71.                Last_SQL_Error:   

  72.          Replicate_Ignore_Server_Ids:   

  73.            Master_Server_Id: 2003307  

  74.            Master_UUID: 6f68eea7-76e9-11e4-8f99-00221904cd5d  

  75.            Master_Info_File: /data/mysqldata/3308/data/master.info  

  76.            SQL_Delay: 0

  77.            SQL_Remaining_Delay: NULL  

  78.     Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it  

  79.           Master_Retry_Count: 86400  

  80.           Master_Bind:   

  81.           Last_IO_Error_Timestamp:   

  82.           Last_SQL_Error_Timestamp:   

  83.               Master_SSL_Crl:   

  84.            Master_SSL_Crlpath:   

  85.            Retrieved_Gtid_Set:   

  86.             Executed_Gtid_Set:   

  87.                Auto_Position: 0  

  88. 1 row in set (0.00 sec)  

  89.   

  90. mysql>   

  91. mysql> flush tables with read lock;  

  92. Query OK, 0 rows affected (0.00 sec)  

  93.   

  94. mysql> show slave status\G  

  95. *************************** 1. row ***************************  

  96.                Slave_IO_State: Waiting for master to send event  

  97.                   Master_Host: 172.32.1.200  

  98.                   Master_User: repl  

  99.                   Master_Port: 3307  

  100.                 Connect_Retry: 60  

  101.         Master_Log_File: mysql-bin.000009  

  102.           Read_Master_Log_Pos: 6531   

  103.                Relay_Log_File: huobiDBtest-relay-bin.000002  

  104.                 Relay_Log_Pos: 6016  

  105.         Relay_Master_Log_File: mysql-bin.000009  

  106.              Slave_IO_Running: Yes  

  107.             Slave_SQL_Running: Yes  

  108.               Replicate_Do_DB:   

  109.           Replicate_Ignore_DB:   

  110.            Replicate_Do_Table:   

  111.        Replicate_Ignore_Table:   

  112.       Replicate_Wild_Do_Table:   

  113.            Replicate_Wild_Ignore_Table:   

  114.             Last_Errno: 0  

  115.           Last_Error:   


    1.    Skip_Counter: 0  



  116.          Exec_Master_Log_Pos: 5853  

  117.                  Relay_Log_Space: 6873  

  118.               Until_Condition: None  

  119.                Until_Log_File:   

  120.                 Until_Log_Pos: 0  

  121.            Master_SSL_Allowed: No  

  122.            Master_SSL_CA_File:   

  123.            Master_SSL_CA_Path:   

  124.               Master_SSL_Cert:   

  125.             Master_SSL_Cipher:   

  126.                Master_SSL_Key:   

  127.         Seconds_Behind_Master: 120  

  128. Master_SSL_Verify_Server_Cert: No  

  129.                 Last_IO_Errno: 0  

  130.                 Last_IO_Error:   

  131.                Last_SQL_Errno: 0  

  132.                Last_SQL_Error:   

  133.   Replicate_Ignore_Server_Ids:   

  134.              Master_Server_Id: 2003307  

    1.              Master_UUID: 6f68eea7-76e9-11e4-8f99-00221904cd5d  


  135.                   Master_Info_File: /data/mysqldata/3308/data/master.info  

  136.                   SQL_Delay: 0  

  137.           SQL_Remaining_Delay: NULL  

  138.       Slave_SQL_Running_State: Waiting for global read lock  

  139.               Master_Retry_Count: 86400  

  140.               Master_Bind:   

  141.       Last_IO_Error_Timestamp:   

  142.      Last_SQL_Error_Timestamp:   

  143.                Master_SSL_Crl:   

  144.               Master_SSL_Crlpath:   

  145.            Retrieved_Gtid_Set:   

  146.             Executed_Gtid_Set:   

  147.                 Auto_Position: 0  

  148. 1 row in set (0.00 sec)  

  149.   

  150. mysql>   

  151. mysql>   

  152. mysql> select * from data03.t01;  

  153. +-----+------+------+  

  154. | id1 | a1   | b1   |  

  155. +-----+------+------+  

  156. |   1 |    1 |    1 |  

  157. |   2 |    2 |    2 |  

  158. |   4 |    4 |    4 |  

  159. |   5 |    5 |    5 |  

  160. |   6 |    6 |    6 |  

  161. +-----+------+------+  

  162. 5 rows in set (0.00 sec)  

  163.   

  164. mysql>   

  165. mysql> unlock tables;  

  166. Query OK, 0 rows affected (0.00 sec)  

  167.   

  168. mysql> show slave status\G  

  169. *************************** 1. row ***************************  

  170.                Slave_IO_State: Waiting for master to send event  

  171.                   Master_Host: 172.32.1.200  

  172.                   Master_User: repl  

  173.                   Master_Port: 3307  

  174.                 Connect_Retry: 60  

  175.             Master_Log_File: mysql-bin.000009  

  176.           Read_Master_Log_Pos: 6531  

  177.                Relay_Log_File: huobiDBtest-relay-bin.000002  

  178.                 Relay_Log_Pos: 6694  

  179.         Relay_Master_Log_File: mysql-bin.000009  

  180.              Slave_IO_Running: Yes  

  181.             Slave_SQL_Running: Yes  

  182.               Replicate_Do_DB:   

  183.           Replicate_Ignore_DB:   

  184.            Replicate_Do_Table:   

  185.        Replicate_Ignore_Table:   

  186.       Replicate_Wild_Do_Table:   

  187.   Replicate_Wild_Ignore_Table:   

  188.         Last_Errno: 0  

  189.      

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
         Last_Error:   
                  Skip_Counter: 0  
       Exec_Master_Log_Pos: 6531   
               Relay_Log_Space: 6873  
               Until_Condition: None  
                Until_Log_File:   
                 Until_Log_Pos: 0  
            Master_SSL_Allowed:  No  
            Master_SSL_CA_File:   
            Master_SSL_CA_Path:   
               Master_SSL_Cert:   
             Master_SSL_Cipher:   
                Master_SSL_Key:   
         Seconds_Behind_Master: 0  
Master_SSL_Verify_Server_Cert:  No  
                 Last_IO_Errno: 0  
                 Last_IO_Error:   
                Last_SQL_Errno: 0  
                Last_SQL_Error:   
   Replicate_Ignore_Server_Ids:   
            Master_Server_Id: 2003307  
            Master_UUID: 6f68eea7-76e9-11e4-8f99-00221904cd5d  
             Master_Info_File: /data/mysqldata/3308/data/master.info  
              SQL_Delay: 0  
           SQL_Remaining_Delay:  NULL  
       Slave_SQL_Running_State: Slave has  read  all  relay log; waiting  for  the slave I/O thread  to  update  it  
            Master_Retry_Count: 86400  
         Master_Bind:   
       Last_IO_Error_Timestamp:   
      Last_SQL_Error_Timestamp:   
                Master_SSL_Crl:   
            Master_SSL_Crlpath:   
            Retrieved_Gtid_Set:   
             Executed_Gtid_Set:   
             Auto_Position: 0  
1 row  in  set  (0.00 sec)  
   
mysql>  select  from  data03.t01;  
+ -----+------+------+  
| id1 | a1   | b1   |  
+ -----+------+------+  
|   1 |    1 |    1 |  
|   2 |   12 |    2 |  
|   5 |    5 |    5 |  
|   6 |    6 |    6 |  
|   8 |    8 |    8 |  
+ -----+------+------+  
rows  in  set  (0.00 sec)




##########################################

.FLUSH TABLES WITH READ LOCK

 

这个命令是全局读锁定,执行了命令之后所有库所有表都被锁定只读。一般都是用在数据库联机备份,这个时候数据库的写操作将被阻塞,读操作顺利进行。

 

解锁的语句也是unlock tables。


2.LOCK TABLES tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE}

 

这个命令是表级别的锁定,可以定制锁定某一个表。例如: lock  tables test read; 不影响其他表的写操作。

解锁语句也是unlock tables。


重点: 

这两个语句在执行的时候都需要注意个特点,就是 隐式提交的语句。在退出MySQL终端的时候都会隐式的执行unlock tables。也就是如果要让表锁定生效就必须一直保持对话。

 

 

P.S.  MYSQL的read lock和wirte lock


read-lock:  允许其他并发的读请求,但阻塞写请求,即可以同时读,但不允许任何写。也叫共享锁

write-lock: 不允许其他并发的读和写请求,是排他的(exclusive)。也叫独占锁






      本文转自crazy_charles 51CTO博客,原文链接:http://blog.51cto.com/douya/1868243,如需转载请自行联系原作者





相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
3月前
|
关系型数据库 MySQL 数据库
数据迁移脚本优化过程:从 MySQL 到 Django 模型表
在大规模的数据迁移过程中,性能问题往往是开发者面临的主要挑战之一。本文将分析一个数据迁移脚本的优化过程,展示如何从 MySQL 数据库迁移数据到 Django 模型表,并探讨优化前后的性能差异。
|
3月前
|
Prometheus 监控 关系型数据库
数据库同步革命:MySQL GTID模式下主从配置的全面解析
数据库同步革命:MySQL GTID模式下主从配置的全面解析
334 0
|
21天前
|
SQL 关系型数据库 MySQL
MySQL的match WITH QUERY EXPANSION 模式是什么?如何使用?
【8月更文挑战第29天】MySQL的match WITH QUERY EXPANSION 模式是什么?如何使用?
31 4
|
1月前
|
存储 关系型数据库 MySQL
MySQL主从同步如何保证数据一致性?
MySQL主从同步如何保证数据一致性?
57 0
MySQL主从同步如何保证数据一致性?
|
1月前
|
缓存 NoSQL 关系型数据库
(八)漫谈分布式之缓存篇:唠唠老生常谈的MySQL与Redis数据一致性问题!
本文来聊一个跟实际工作挂钩的老生常谈的问题:分布式系统中的缓存一致性。
110 10
|
2月前
|
SQL 监控 关系型数据库
面试题MySQL问题之主从复制的数据一致性问题如何解决
面试题MySQL问题之主从复制的数据一致性问题如何解决
29 1
|
2月前
|
缓存 NoSQL 关系型数据库
mysql和Redis如何保持数据一致性
文档讨论了在系统重建时如何处理数据库和缓存的一致性问题。关键点包括:数据库(如MySQL)和分布式ID生成器可能不宜轻易替换,而代码可以通过兼容性改造来适应新系统。文中以CPU、Memory和Disk的比喻解释了缓存(如Redis)在性能优化中的作用。为确保MySQL和Redis间的一致性,提到了四种策略:Read/Write Through、Write Behind、Cache Aside(先写数据库后更新缓存或先删除缓存后更新数据库)以及先写缓存后写数据库。考虑到读多写少和低频写操作的业务场景,最终选择了先写数据库后更新缓存的策略,并利用canal保证消息顺序性以实现最终一致性。
|
3月前
|
关系型数据库 MySQL 分布式数据库
PolarDB产品使用问题之要验证MySQL迁移后的数据库数据与迁移前的数据一致性,该怎么办
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
PolarDB产品使用问题之要验证MySQL迁移后的数据库数据与迁移前的数据一致性,该怎么办
|
2月前
|
分布式计算 DataWorks 关系型数据库
MaxCompute操作报错合集之配置mysql数据源querysql模式,同步到MC时遇到报错,该怎么处理
MaxCompute是阿里云提供的大规模离线数据处理服务,用于大数据分析、挖掘和报表生成等场景。在使用MaxCompute进行数据处理时,可能会遇到各种操作报错。以下是一些常见的MaxCompute操作报错及其可能的原因与解决措施的合集。
|
3月前
|
JSON 关系型数据库 MySQL
实时计算 Flink版产品使用问题之在使用CDAS语法同步MySQL数据到Hologres时,如果开启了字段类型宽容模式,MySQL中的JSON类型会被转换为什么
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。

热门文章

最新文章