精华内容
下载资源
问答
  • 文章目录准备知识定义检查约束使用SSMS工具定义检查约束使用SQL方式定义检查约束方式一:在创建数据表的时候定义检查约束方式二:修改数据表定义检查约束删除检查约束使用SSMS工具删除检查约束方式一:在对象资源...




    准备知识

        检查约束在表中定义一个对输入的数据按照设置的逻辑进行检查的标识符.
        一旦表中某列设置了检查约束,则在向表中添加数据时,会使用这个约束对输入的数据按照设置的逻辑进行检查。

    定义检查约束

    使用SSMS工具定义检查约束
    1. 展开“数据库”,然后展开相应的数据库,再展开数据库中的“表”,右击需要定义检查约束的数据表,选择“设计”。
      在这里插入图片描述
    2. 进入表设计器界面,点击需要定义检查约束的列,选择“Check约束”。
      在这里插入图片描述
    3. 进入“Check约束”对话框,点击“添加”,在“表达式”中输入相关表达式(如果是选值,则是“ 列名=‘值’ Or 列名=‘值’ ”,如果是范围,则是“ 列名 between 值 And 值 ”)。
      在这里插入图片描述
    4. 在“(名称)”中输入检查约束的名称,点击“关闭”。
      在这里插入图片描述
    5. 点击保存键,或者按Ctrl+F5键进行保存。展开数据表,展开“约束”,可以看到定义的检查约束。
      在这里插入图片描述

    使用SQL方式定义检查约束
    方式一:在创建数据表的时候定义检查约束
    1. 在SSMS工具栏中单击“新建查询”,打开“SQL编辑器”窗口
      在这里插入图片描述
    2. 输入创建SQL代码
    USE schoolDB                                                 --打开数据库schoolDB
    GO
    IF EXISTS(SELECT * FROM sysobjects WHERE name='student') 
    DROP TABLE student                --检查student是否已经存在,如果存在,则删除
    GO
    CREATE TABLE student                                           --表名为student
    (
    	  StuID int NOT NULL,                                           --学生学号
    	  StuName varchar(15) NOT NULL,                                 --学生姓名
    	  Sex char(2) CHECK(Sex='男' Or Sex='女') NULL,                                             --性别
    	  Major varchar(20) NULL,                                      --所选专业
    )
    
    
    
    1. 点击“分析”按钮,或按住Ctrl+F5,对SQL代码进行语法分析,确保SQL语句语法正确。
      在这里插入图片描述
    2. 点击“执行”按钮,或按住F5,执行SQL代码。
      在这里插入图片描述
    3. 查看数据表中的约束。
      在这里插入图片描述

    方式二:修改数据表定义检查约束
    1. 在SSMS工具栏中单击“新建查询”,打开“SQL编辑器”窗口
      在这里插入图片描述
    2. 输入创建SQL代码
    USE schoolDB                                                 --打开数据库schoolDB
    GO
    ALTER TABLE student
    ADD CONSTRAINT CK_student_Sex CHECK(Sex='男' Or Sex='女') --对Sex列定义检查约束
    
    
    1. 点击“分析”按钮,或按住Ctrl+F5,对SQL代码进行语法分析,确保SQL语句语法正确。
      在这里插入图片描述
    2. 点击“执行”按钮,或按住F5,执行SQL代码。
      在这里插入图片描述
    3. 查看数据表中的约束。
      在这里插入图片描述


    删除检查约束

    使用SSMS工具删除检查约束
    方式一:在对象资源管理器中删除检查约束
    1. 展开需要删除检查约束的数据表,然后再展开“约束”。
      在这里插入图片描述
    2. 右击需要删除的检查约束,选择“删除”。
      在这里插入图片描述
    3. 在删除对象界面,点击“确定”,即可完成检查约束删除。
      在这里插入图片描述

    方式二:在表设计器中删除检查约束
    1. 右击需要删除检查约束的数据表,选择“设计”。
      在这里插入图片描述

    2. 进入表设计器界面,点击鼠标,选择“Check约束”。
      在这里插入图片描述

    3. 在“Check约束”对话框中选择需要删除的检查约束,点击“删除”,完成检查约束的删除。
      在这里插入图片描述


    使用SQL方式删除检查约束
    1. 在SSMS工具栏中单击“新建查询”,打开“SQL编辑器”窗口
      在这里插入图片描述

    2. 输入创建SQL代码

    USE schoolDB                                                 --打开数据库schoolDB
    GO
    ALTER TABLE student
    DROP CONSTRAINT CK_student_Sex --删除Sex列的检查约束
    
    
    1. 点击“分析”按钮,或按住Ctrl+F5,对SQL代码进行语法分析,确保SQL语句语法正确。
      在这里插入图片描述
    2. 点击“执行”按钮,或按住F5,执行SQL代码。
      在这里插入图片描述
    3. 检查约束已被删除。
      在这里插入图片描述



    展开全文
  • word2007 德语拼写检查

    热门讨论 2013-01-31 18:11:31
    office2007 word07版 输入德语时自动检查而且可以和其他语言自由切换
  • nginx后端节点的健康检查

    千次阅读 2018-11-18 00:18:44
    本文主要介绍nginx后端节点的健康检查,在此之前我们先来介绍下nignx反向代理主要使用的模块。 模块介绍 我们在使用nginx做反向代理都会使用到以下两个模块: 1.ngx_http_proxy_module 定义允许将请求传递到另一...

    简介

    本文主要介绍nginx后端节点的健康检查,在此之前我们先来介绍下nignx反向代理主要使用的模块。

    nginx原生模块介绍

    我们在使用nginx做反向代理都会使用到以下两个模块:
    1.ngx_http_proxy_module
    定义允许将请求传递到另一台服务器。此模块下常用指令如下:

    proxy_pass
    proxy_cache
    proxy_connect_timeout
    proxy_read_timeout
    proxy_send_timeout
    proxy_next_upstream
    

    2.ngx_http_upstream_module
    用于定义可由proxy_pass,fastcgi_pass等指令引用的服务器组。此模块下常用指令如下:

    upstream
    server
    ip_hash
    

    默认负载均衡配置

    http {
        upstream myapp1 {
            server srv1.example.com;
            server srv2.example.com;
            server srv3.example.com;
        }
    
        server {
            listen 80;
    
            location / {
                proxy_pass http://myapp1;
            }
        }
    }
    

    此时nginx默认的负载均衡策略是轮询外,还有其他默认参数,如下:

    http {
        upstream myapp1 {
            server srv1.example.com weight=1 max_fails=1 fail_timeout=10;
            server srv2.example.com weight=1 max_fails=1 fail_timeout=10;
            server srv3.example.com weight=1 max_fails=1 fail_timeout=10;
        }
    
        server {
            listen 80;
            proxy_send_timeout=60;
            proxy_connect_timeout=60;
            proxy_read_timeout=60;
            proxy_next_upstream=error timeout;
    
            location / {
                proxy_pass http://myapp1;
            }
        }
    }
    

    其中:
    1.故障转移

    Syntax: 	proxy_read_timeout time;
    Default: 	
    proxy_read_timeout 60s;
    Context: 	http, server, location
    定义从代理服务器读取响应的超时。 仅在两个连续的读操作之间设置超时,而不是为整个响应的传输。 如果代理服务器在此时间内未传输任何内容,则关闭连接。
    
    Syntax: 	proxy_connect_timeout time;
    Default: 	
    proxy_connect_timeout 60s;
    Context: 	http, server, location
    定义与代理服务器建立连接的超时。 应该注意,此超时通常不会超过75秒。
    
    
    Syntax: 	proxy_send_timeout time;
    Default: 	
    proxy_send_timeout 60s;
    Context: 	http, server, location
    设置将请求传输到代理服务器的超时。 仅在两个连续的写操作之间设置超时,而不是为整个请求的传输。 如果代理服务器在此时间内未收到任何内容,则关闭连接
    
    Syntax: 	proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 | non_idempotent | off ...;
    Default: 	
    proxy_next_upstream error timeout;
    Context: 	http, server, location
    指定在何种情况下一个失败的请求应该被发送到下一台后端服务器:
    error      和后端服务器建立连接时,或者向后端服务器发送请求时,或者从后端服务器接收响应头时,出现错误
    timeout    和后端服务器建立连接时,或者向后端服务器发送请求时,或者从后端服务器接收响应头时,出现超时
    invalid_header  后端服务器返回空响应或者非法响应头
    http_500   后端服务器返回的响应状态码为500
    http_502   后端服务器返回的响应状态码为502
    http_503   后端服务器返回的响应状态码为503
    http_504   后端服务器返回的响应状态码为504
    http_404   后端服务器返回的响应状态码为404
    off        停止将请求发送给下一台后端服务器
    

    从以上几个指令可以看出,在默认配置下,后端节点一旦出现error和timeout情况时,nginx会通过proxy_next_upstream进行故障转移,将发往不健康节点的请求,自动转移至健康节点。其中timeout设置和proxy_send_timeout time、proxy_connect_timeout time、proxy_read_timeout time有关。除了error、timeout,我们可以设置更详细的触发条件,如http_502、http_503等。

    注意:只有在没有向客户端发送任何数据以前,将请求转给下一台后端服务器才是可行的。也就是说,如果在传输响应到客户端时出现错误或者超时,这类错误是不可能恢复的。

    2.健康检查

    Syntax: 	server address [parameters];
    Default: 	—
    Context: 	upstream
    max_fails=number   设定Nginx与服务器通信的尝试失败的次数。在fail_timeout参数定义的时间段内,如果失败的次数达到此值,Nginx就认为服务器不可用。此时在接下来的fail_timeout时间段,服务器不会再被尝试。失败的尝试次数默认是1。设为0就会停止统计尝试次数,即不对后端节点进行健康检查。认为服务器是一直可用的。
      
    fail_timeout=time  设定服务器被认为不可用的时间段以及统计失败尝试次数的时间段。在这段时间中,服务器失败次数达到指定的尝试次数,服务器就被认为不可用。
    默认情况下,该超时时间是10秒。
    

    以上有几点需要解释:
    1.失败次数中的失败是怎么定义的?
    官网解释是指由proxy_next_upstream,fastcgi_next_upstream,uwsgi_next_upstream,scgi_next_upstream,memcached_next_upstream和grpc_next_upstream指令定义,也是前面说的error、time、http_xxx状态码等。
    2.如果mail_fail为0,此时健康检查无效。因此此时整个nginx,只会由proxy_next_upstream判断,进行相关故障转移。

    小结

    在使用nginx上述的两个模块由以下缺点:
    1.fail_time内的失败检测,超时时间以系统设置为主,效率低,等待超时影响性能;
    2.后端一旦有问题,除后端禁用的fail_time时间段,其他时间nginx会把请求转发给不健康节点的,然后再转发给别的服务器,这样以来就浪费了一次转发。

    因此除了上面介绍的nginx自带模块,还有一个更专业的模块,来专门提供负载均衡器内节点的健康检查的。这个就是淘宝技术团队开发的nginx模块。

    nginx_upstream_check_module模块

    借助淘宝技术团队开发的nginx模快nginx_upstream_check_module来检测后方realserver的健康状态,如果后端服务器不可用,则会将其踢出upstream,所有的请求不转发到这台服务器。当期恢复正常时,将其加入upstream。

    在淘宝自己的tengine上是自带了该模块的,大家可以访问淘宝Tengine官网来获取该版本的nginx,也可以到Gitbub
    如果没有使用淘宝的tengine的话,可以通过补丁的方式来添加该模块到我们自己的nginx
    中。

    #打补丁
    #注意不同版本对应的补丁
    cd nginx-1.6.0
    patch -p1 < ../nginx_upstream_check_module-master/check_1.5.12+.patch
     ./configure --user=nginx --group=nginx --prefix=/usr/local/nginx1.6 --sbin-path=/usr/local/nginx1.6 --conf-path=/usr/local/nginx1.6/nginx.conf --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --with-http_ssl_module --with-http_stub_status_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_sub_module --with-pcre=/usr/local/src/nginx/pcre-8.36 --with-zlib=/usr/local/src/nginx/zlib-1.2.8 --add-module=/usr/local/src/nginx/ngx_cache_purge-2.1 --add-module=/usr/local/src/nginx/headers-more-nginx-module-master --add-module=/usr/local/src/nginx/nginx_upstream_check_module-master
    
    make
    #不要执行make install命令
    
    cd /usr/local/nginx1.6
    #备份命令
    cp nginx nginx.bak
    nginx -s stop
    cp -r /usr/local/src/nginx/nginx-1.6.0/objs/nginx .
    

    打完补丁后,可进行如下配置:

      http {
    
            upstream cluster {
    
                # simple round-robin
                server 192.168.0.1:80;
                server 192.168.0.2:80;
    
                check interval=5000 rise=1 fall=3 timeout=4000;
    
                #check interval=3000 rise=2 fall=5 timeout=1000 type=ssl_hello;
    
                #check interval=3000 rise=2 fall=5 timeout=1000 type=http;
                #check_http_send "HEAD / HTTP/1.0\r\n\r\n";
                #check_http_expect_alive http_2xx http_3xx;
            }
    
            server {
                listen 80;
    
                location / {
                    proxy_pass http://cluster;
                }
    
                location /status {
                    check_status;
    
                    access_log   off;
                    allow SOME.IP.ADD.RESS;
                    deny all;
               }
            }
    
        }
    

    其中:

    Syntax:  check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]
    Default: 如果没有配置参数,默认值是:interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp
    Context: upstream
     
    该指令可以打开后端服务器的健康检查功能。指令后面的参数意义是:
    interval:向后端发送的健康检查包的间隔,单位为毫秒。
    fall(fall_count): 如果连续失败次数达到fall_count,服务器就被认为是down。
    rise(rise_count): 如果连续成功次数达到rise_count,服务器就被认为是up。
    timeout: 后端健康请求的超时时间,单位毫秒。
    default_down: 设定初始时服务器的状态,如果是true,就说明默认是down的,如果是false,就是up的。默认值是true,也就是一开始服务器认为是不可用,要等健康检查包达到一定成功次数以后才会被认为是健康的。
    type:健康检查包的类型,现在支持以下多种类型:
         tcp:简单的tcp连接,如果连接成功,就说明后端正常。
         ssl_hello:发送一个初始的SSL hello包并接受服务器的SSL hello包。
         http:发送HTTP请求,通过后端的回复包的状态来判断后端是否存活。
         mysql: 向mysql服务器连接,通过接收服务器的greeting包来判断后端是否存活。
         ajp:向后端发送AJP协议的Cping包,通过接收Cpong包来判断后端是否存活。
         port: 指定后端服务器的检查端口。你可以指定不同于真实服务的后端服务器的端口,比如后端提供的是443端口的应用,你可以去检查80端口的状态来判断后端健康状况。默认是0,表示跟后端server提供真实服务的端口一样。该选项出现于Tengine-1.4.0。
         
    Syntax: check_keepalive_requests request_num
    Default: 1
    Context: upstream
    该指令可以配置一个连接发送的请求数,其默认值为1,表示Tengine完成1次请求后即关闭连接。
     
    Syntax: check_http_send http_packet
    Default: "GET / HTTP/1.0\r\n\r\n"
    Context: upstream
    该指令可以配置http健康检查包发送的请求内容。为了减少传输数据量,推荐采用"HEAD"方法。
     
    当采用长连接进行健康检查时,需在该指令中添加keep-alive请求头,如:"HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n"。 同时,在采用"GET"方法的情况下,请求uri的size不宜过大,确保可以在1个interval内传输完成,否则会被健康检查模块视为后端服务器或网络异常。
    
    Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]
    Default: http_2xx | http_3xx
    Context: upstream
    该指令指定HTTP回复的成功状态,默认认为2XX和3XX的状态是健康的。
    

    例子如下:

    server{
            listen 80;
            
            upstream test{
            	server 192.168.3.12:8080 weight=5 max_fails=3 fail_timeout=10s;
           		server 192.168.3.13:8080 weight=5 max_fails=3 fail_timeout=10s;
           		 
            	check interval=5000 rise=1 fall=3 timeout=4000 type=http default_down=false;
          		check_http_send "HEAD /test.jsp HTTP/1.0\r\n\r\n";
          	 	check_http_expect_alive http_2xx http_3xx;
           }
    
            location / {
    
                    proxy_set_header X-Real-IP        $remote_addr;
                    proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
                    proxy_pass http://test;
                    proxy_next_upstream error timeout  http_500 http_502 http_503;
            }
    	#后端阶段健康状态监控
            location /status {
                    check_status;
                    access_log off;
            }
    }
    

    以上我们同时使用了nginx原生的及淘宝的健康检查模块,但是淘宝的间隔时是毫秒级,而且可以自定义监控url,定制监控页,响应速度快,比原生的敏感度要高。

    展开全文
  • findbugs 代码检查 eclipse插件 3.0.0版本

    千次下载 热门讨论 2014-11-21 16:27:58
    最新版下载地址:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/ ...安装方法:直接解压后放到eclipse/plugin目录下即可,重启eclipse 错误代码中英对照及修改方案见我的博客
  • MySQL 8.0 新特性之检查约束(CHECK)

    千次阅读 多人点赞 2020-06-05 14:52:42
    介绍 MySQL 8.0 增加的新功能:检查约束(CHECK ),定义列级检查约束和表级检查约束,检查约束的 enforced 选项,检查约束的使用限制。

    大家好,我是只谈技术不剪发的 Tony 老师。这次我们来介绍一个 MySQL 8.0 增加的新功能:检查约束(CHECK )。

    SQL 中的检查约束属于完整性约束的一种,可以用于约束表中的某个字段或者一些字段必须满足某个条件。例如用户名必须大写、余额不能小于零等。

    我们常见的数据库都实现了检查约束,例如 Oracle、SQL Server、PostgreSQL 以及 SQLite;然而 MySQL 一直以来没有真正实现该功能,直到最新的 MySQL 8.0.16。

    MySQL 8.0.15 之前

    在 MySQL 8.0.15 以及之前的版本中,虽然 CREATE TABLE 语句允许CHECK (expr)形式的检查约束语法,但实际上解析之后会忽略该子句。例如

    mysql> select version();
    +-----------+
    | version() |
    +-----------+
    | 8.0.15    |
    +-----------+
    1 row in set (0.00 sec)
    
    mysql> CREATE TABLE t1
        -> (
        ->   c1 INT CHECK (c1 > 10),
        ->   c2 INT ,
        ->   c3 INT CHECK (c3 < 100),
        ->   CONSTRAINT c2_positive CHECK (c2 > 0),
        ->   CHECK (c1 > c3)
        -> );
    Query OK, 0 rows affected (0.33 sec)
    
    mysql> show create table t1\G
    *************************** 1. row ***************************
           Table: t1
    Create Table: CREATE TABLE `t1` (
      `c1` int(11) DEFAULT NULL,
      `c2` int(11) DEFAULT NULL,
      `c3` int(11) DEFAULT NULL
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
    1 row in set (0.00 sec)
    

    虽然我们在定义时指定了各种 CHECK 选项,但最终的表结构中不包含任何检查约束。这也意味着我们可以插入非法的数据:

    mysql> insert into t1(c1, c2, c3) values(1, -1, 100);
    Query OK, 1 row affected (0.06 sec)
    

    如果我们想要在 MySQL 8.0.15 之前实现类似的检查约束,可以使用触发器;或者创建一个包含 WITH CHECK OPTION 选项的视图,然后通过视图插入或修改数据。

    MySQL 8.0.16 之后

    MySQL 8.0.16 于 2019 年 4 月 25 日发布,终于带来了我们期待已久的 CHECK 约束功能,而且对于所有的存储引擎都有效。CREATE TABLE 语句允许以下形式的 CHECK 约束语法,可以指定列级约束和表级约束:

    [CONSTRAINT [symbol]] CHECK (expr) [[NOT] ENFORCED]
    

    其中,可选的 symbol 参数用于给约束指定一个名称。如果省略该选项,MySQL 将会产生一个以表名开头、加上 _chk_ 以及一个数字编号(1、2、3 …)组成的名字(table_name_chk_n)。约束名称最大长度为 64 个字符,而且区分大小写。

    expr 是一个布尔表达式,用于指定约束的条件;表中的每行数据都必须满足 expr 的结果为 TRUE 或者 UNKNOWN(NULL)。如果表达式的结果为 FALSE,将会违反约束。

    可选的 ENFORCED 子句用于指定是否强制该约束:

    • 如果忽略或者指定了 ENFORCED,创建并强制该约束;
    • 如果指定了 NOT ENFORCED,创建但是不强制该约束。这也意味着约束不会生效。

    CHECK 约束可以在列级指定,也可以在表级指定。

    列级检查约束

    列级约束只能出现在字段定义之后,而且只能针对该字段进行约束。例如:

    mysql> select version();
    +-----------+
    | version() |
    +-----------+
    | 8.0.16    |
    +-----------+
    1 row in set (0.00 sec)
    
    mysql> CREATE TABLE t1
        -> (
        ->   c1 INT CHECK (c1 > 10),
        ->   c2 INT CONSTRAINT c2_positive CHECK (c2 > 0),
        ->   c3 INT CHECK (c3 < 100)
        -> );
    Query OK, 0 rows affected (0.04 sec)
    
    mysql> show create table t1\G
    *************************** 1. row ***************************
           Table: t1
    Create Table: CREATE TABLE `t1` (
      `c1` int DEFAULT NULL,
      `c2` int DEFAULT NULL,
      `c3` int DEFAULT NULL,
      CONSTRAINT `c2_positive` CHECK ((`c2` > 0)),
      CONSTRAINT `t1_chk_1` CHECK ((`c1` > 10)),
      CONSTRAINT `t1_chk_2` CHECK ((`c3` < 100))
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
    1 row in set (0.00 sec)
    

    其中,字段 c1 和 c3 上的检查约束使用了系统生成的名称;c2 上的检查约束使用了自定义名称。

    📝SQL 标准中所有的约束(主键、唯一约束、外键、检查约束等)都属于相同的命名空间,意味着它们相互不能重名。但在 MySQL 中,每个数据库中的约束类型属于自己的命名空间;因此,主键和检查约束可以重名,但是两个检查约束不能重名。

    我们插入一条测试数据:

    mysql> insert into t1(c1, c2, c3) values(1, -1, 100);
    ERROR 3819 (HY000): Check constraint 'c2_positive' is violated.
    

    插入数据的三个字段都违反了约束,结果显示的是违反了 c2_positive;因为它按照名字排在第一,由此也可以看出 MySQL 按照约束的名字排序依次进行检查。

    我们再插入一条测试数据:

    mysql> insert into t1(c1, c2, c3) values(null, null, null);
    Query OK, 1 row affected (0.00 sec)
    

    数据插入成功,所以 NULL 值并不会违反检查约束。

    表级检查约束

    表级约束独立于字段的定义,而且可以针对多个字段进行约束,甚至可以出现在字段定义之前。例如:

    mysql> drop table t1;
    Query OK, 0 rows affected (0.04 sec)
    
    mysql> CREATE TABLE t1
        -> (
        ->   CHECK (c1 <> c2),
        ->   c1 INT,
        ->   c2 INT,
        ->   c3 INT,
        ->   CONSTRAINT c1_nonzero CHECK (c1 <> 0),
        ->   CHECK (c1 > c3)
        -> );
    Query OK, 0 rows affected (0.04 sec)
    
    mysql> show create table t1\G
    *************************** 1. row ***************************
           Table: t1
    Create Table: CREATE TABLE `t1` (
      `c1` int DEFAULT NULL,
      `c2` int DEFAULT NULL,
      `c3` int DEFAULT NULL,
      CONSTRAINT `c1_nonzero` CHECK ((`c1` <> 0)),
      CONSTRAINT `t1_chk_1` CHECK ((`c1` <> `c2`)),
      CONSTRAINT `t1_chk_2` CHECK ((`c1` > `c3`))
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
    1 row in set (0.00 sec)
    

    第一个约束 t1_chk_1 出现在字段定义之前,但是仍然可以引用 c1 和 c2;第二个约束 c1_nonzero 使用了自定义的名称;第三个约束 t1_chk_2 在所有字段定义之后。

    我们同样插入一些测试数据:

    mysql> insert into t1(c1, c2, c3) values(1, 2, 3);
    ERROR 3819 (HY000): Check constraint 't1_chk_2' is violated.
    
    mysql> insert into t1(c1, c2, c3) values(null, 2, 3);
    Query OK, 1 row affected (0.01 sec)
    

    第一条记录中的 c1 小于 c3,违反了检查约束 t1_chk_2;第二条记录中的 c1 为 NULL,检查约束 t1_chk_2 的结果为 UNKNOWN,不违法约束。

    强制选项

    使用默认方式或者 ENFORCED 选项创建的约束处于强制检查状态,我们也可以将其修改为 NOT ENFORCED,从而忽略检查:

    ALTER TABLE tbl_name
    ALTER {CHECK | CONSTRAINT} symbol [NOT] ENFORCED
    

    修改之后的检查约束仍然存在,但是不会执行检查。例如:

    mysql> alter table t1 
        -> alter check t1_chk_1 not enforced;
    Query OK, 0 rows affected (0.02 sec)
    Records: 0  Duplicates: 0  Warnings: 0
    
    mysql> show create table t1\G
    *************************** 1. row ***************************
           Table: t1
    Create Table: CREATE TABLE `t1` (
      `c1` int DEFAULT NULL,
      `c2` int DEFAULT NULL,
      `c3` int DEFAULT NULL,
      CONSTRAINT `c1_nonzero` CHECK ((`c1` <> 0)),
      CONSTRAINT `t1_chk_1` CHECK ((`c1` <> `c2`)) /*!80016 NOT ENFORCED */,
      CONSTRAINT `t1_chk_2` CHECK ((`c1` > `c3`))
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
    1 row in set (0.00 sec)
    

    从最新的定义可以看出,t1_chk_1 处于 NOT ENFORCED 状态。我们插入一条违反该约束的数据:

    mysql> insert into t1(c1, c2, c3) values(1, 1, 0);
    Query OK, 1 row affected (0.01 sec)
    

    该记录的 c1 和 c2 相等,但是插入成功。

    如果我们需要迁移一些低版本的历史数据时,它们可能会违反新的检查约束;此时可以先将该约束禁用,等数据迁移并处理完成之后,再次启用强制选项。

    检查约束限制

    MySQL 中的 CHECK 条件表达式必须满足以下规则,否则无法创建检查约束:

    • 允许使用非计算列和计算列,但是不允许使用 AUTO_INCREMENT 字段或者其他表中的字段。
    • 允许使用字面值、确定性内置函数(即使不同用户,多次调用该函数,只要输入相同结果就相同)以及运算符。非确定性函数包括:CONNECTION_ID()、CURRENT_USER()、NOW() 等等,它们不能用于检查约束。
    • 不允许使用存储函数或者自定义函数。
    • 不允许使用存储过程和函数参数。
    • 不允许使用变量,包括系统变量、用户定义变量和存储程序的局部变量。
    • 不允许使用子查询。

    另外,禁用在 CHECK 约束字段上定义外键约束的参照操作(ON UPDATE、ON DELETE);同理,存在外键约束参照操作的字段上也不允许创建 CHECK 约束。

    对于 INSERT、UPDATE、REPLACE、LOAD DATA 以及 LOAD XML 语句,如果违反检查约束将会返回错误。此时,对于已经修改的数据处理取决于存储引擎是否支持事务,以及是否使用了严格 SQL 模式

    对于 INSERT IGNORE、UPDATE IGNORE、REPLACE、LOAD DATA … IGNORE 以及 LOAD XML … IGNORE 语句,如果违反检查约束将会返回警告并且跳过存在问题的数据行。

    如果约束表达式的结果类型和字段的数据类型不同,MySQL 将会执行隐式类型转换;如果类型转换失败或者丢失精度,将会返回错误。

    总结

    MySQL 8.0.16 新增的检查约束提高了 MySQL 实现业务完整性约束的能力,也使得 MySQL更加遵循 SQL 标准。😎

    如果觉得文章对你有用,请不要白嫖!欢迎关注❤️、评论📝、点赞👍!

    展开全文
  • Flink 检查点(checkpoint)

    千次阅读 2020-03-25 17:35:00
    它使用一种被称为"检查点"(checkpoint)的特性,在出现故障时将系统重置回正确状态。下面通过简单的类比来解释检查点的作用。 假设你和两位朋友正在数项链上有多少颗珠子,如下图所示。你捏住珠子,边数边拨,每拨...

    Flink具体如何保证exactly-once呢? 它使用一种被称为"检查点"(checkpoint)的特性,在出现故障时将系统重置回正确状态。下面通过简单的类比来解释检查点的作用。

    假设你和两位朋友正在数项链上有多少颗珠子,如下图所示。你捏住珠子,边数边拨,每拨过一颗珠子就给总数加一。你的朋友也这样数他们手中的珠子。当你分神忘记数到哪里时,怎么办呢? 如果项链上有很多珠子,你显然不想从头再数一遍,尤其是当三人的速度不一样却又试图合作的时候,更是如此(比如想记录前一分钟三人一共数了多少颗珠子,回想一下一分钟滚动窗口)。

    于是,你想了一个更好的办法: 在项链上每隔一段就松松地系上一根有色皮筋,将珠子分隔开; 当珠子被拨动的时候,皮筋也可以被拨动; 然后,你安排一个助手,让他在你和朋友拨到皮筋时记录总数。用这种方法,当有人数错时,就不必从头开始数。相反,你向其他人发出错误警示,然后你们都从上一根皮筋处开始重数,助手则会告诉每个人重数时的起始数值,例如在粉色皮筋处的数值是多少。

    Flink检查点的作用就类似于皮筋标记。数珠子这个类比的关键点是: 对于指定的皮筋而言,珠子的相对位置是确定的; 这让皮筋成为重新计数的参考点。总状态(珠子的总数)在每颗珠子被拨动之后更新一次,助手则会保存与每根皮筋对应的检查点状态,如当遇到粉色皮筋时一共数了多少珠子,当遇到橙色皮筋时又是多少。当问题出现时,这种方法使得重新计数变得简单。

    1、Flink的检查点算法

    Flink检查点的核心作用是确保状态正确,即使遇到程序中断,也要正确。记住这一基本点之后,Flink为用户提供了用来定义状态的工具。

     1 val dataDS: DataStream[String] = env.readTextFile("input/data.txt")
     2 
     3 val mapDS: DataStream[(String, String, String)] = dataDS.map(data => {
     4     val datas = data.split(",")
     5     (datas(0), datas(1), datas(2))
     6 })
     7 val keyDS: KeyedStream[(String, String, String), Tuple] = mapDS.keyBy(0)
     8 
     9 keyDS.mapWithState{
    10     case ( t, buffer ) => {
    11         (t, buffer)
    12     }
    13 }

     

    我们用一个例子来看检查点是如何运行的:

    以下这个Scala程序按照输入记录的第一个字段(一个字符串)进行分组并维护第三个字段的计数状态.

     1 env.enableCheckpointing(1000, CheckpointingMode.EXACTLY_ONCE)
     2 
     3 val dataDS: DataStream[String] = env.readTextFile("input/data.txt")
     4 
     5 val mapDS: DataStream[(String, String, Int)] = dataDS.map(data => {
     6     val datas = data.split(",")
     7     (datas(0), datas(1), datas(2).toInt)
     8 })
     9 val keyDS: KeyedStream[(String, String, Int), Tuple] = mapDS.keyBy(0)
    10 
    11 val mapStateDS = keyDS.mapWithState[(String, String, Int), Int] {
    12     case (t:(String, String, Int), buffer:Option[Int]) => {
    13         val i: Int = buffer.getOrElse(0)
    14         println("buffer>>>" + i)
    15         (t, Option(t._3 + i))
    16     }
    17 }
    18 mapStateDS.print()

     

    该程序有两个算子: keyBy算子用来将记录按照第一个元素(一个字符串)进行分组,根据该key将数据进行重新分区,然后将记录再发送给下一个算子: 有状态的map算子(mapWithState)。map算子在接收到每个元素后,将输入记录的第三个字段的数据加到现有总数中,再将更新过的元素发送出去。下图表示程序的初始状态: 输入流中的6条记录被检查点分割线(checkpoint barrier)隔开,所有的map算子状态均为0(计数还未开始)。所有key为sensor_1的记录将被顶层的map算子处理,所有key为b的记录将被中间层的map算子处理,所有key为c的记录则将被底层的map算子处理。

    上图是程序的初始状态。注意,a、b、c三组的初始计数状态都是0,即三个圆柱上的值。ckpt表示检查点分割线(checkpoint barriers)。每条记录在处理顺序上严格地遵守在检查点之前或之后的规定,例如["b",2]在检查点之前被处理,["a",2]则在检查点之后被处理。

    当该程序处理输入流中的6条记录时,涉及的操作遍布3个并行实例(节点、CPU内核等)。那么,检查点该如何保证exactly-once呢?

    检查点分割线和普通数据记录类似。它们由算子处理,但并不参与计算,而是会触发与检查点相关的行为。当读取输入流的数据源(在本例中与keyBy算子内联)遇到检查点屏障时,它将其在输入流中的位置保存到持久化存储中。如果输入流来自消息传输系统(Kafka),这个位置就是偏移量。Flink的存储机制是插件化的,持久化存储可以是分布式文件系统,如HDFS。下图展示了这个过程。

    当Flink数据源(在本例中与keyBy算子内联)遇到检查点分界线(barrier)时,它会将其在输入流中的位置保存到持久化存储中。这让 Flink可以根据该位置重启。

    检查点像普通数据记录一样在算子之间流动。当map算子处理完前3条数据并收到检查点分界线时,它们会将状态以异步的方式写入持久化存储,如下图所示。

    位于检查点之前的所有记录(["b",2]、["b",3]和["c",1])被map算子处理之后的情况。此时,持久化存储已经备份了检查点分界线在输入流中的位置(备份操作发生在barrier被输入算子处理的时候)。map算子接着开始处理检查点分界线,并触发将状态异步备份到稳定存储中这个动作。

    当map算子的状态备份和检查点分界线的位置备份被确认之后,该检查点操作就可以被标记为完成,如下图所示。我们在无须停止或者阻断计算的条件下,在一个逻辑时间点(对应检查点屏障在输入流中的位置)为计算状态拍了快照。通过确保备份的状态和位置指向同一个逻辑时间点,后文将解释如何基于备份恢复计算,从而保证exactly-once。值得注意的是,当没有出现故障时,Flink检查点的开销极小,检查点操作的速度由持久化存储的可用带宽决定。回顾数珠子的例子: 除了因为数错而需要用到皮筋之外,皮筋会被很快地拨过。

    检查点操作完成,状态和位置均已备份到稳定存储中。输入流中的所有数据记录都已处理完成。值得注意的是,备份的状态值与实际的状态值是不同的。备份反映的是检查点的状态。

    如果检查点操作失败,Flink可以丢弃该检查点并继续正常执行,因为之后的某一个检查点可能会成功。虽然恢复时间可能更长,但是对于状态的保证依旧很有力。只有在一系列连续的检查点操作失败之后,Flink才会抛出错误,因为这通常预示着发生了严重且持久的错误。 现在来看看下图所示的情况: 检查点操作已经完成,但故障紧随其后。

     

    在这种情况下,Flink会重新拓扑(可能会获取新的执行资源),将输入流倒回到上一个检查点,然后恢复状态值并从该处开始继续计算。在本例中,["a",2]、["a",2]和["c",2]这几条记录将被重播。

    下图展示了这一重新处理过程。从上一个检查点开始重新计算,可以保证在剩下的记录被处理之后,得到的map算子的状态值与没有发生故障时的状态值一致。

    Flink将输入流倒回到上一个检查点屏障的位置,同时恢复map算子的状态值。然后,Flink从此处开始重新处理。这样做保证了在记录被处理之后,map算子的状态值与没有发生故障时的一致。

    Flink检查点算法的正式名称是异步分界线快照(asynchronous barrier snapshotting)。该算法大致基于Chandy-Lamport分布式快照算法

    检查点是Flink最有价值的创新之一,因为它使Flink可以保证exactly-once,并且不需要牺牲性能

    2、Flink+Kafka如何实现端到端的Exactly-once语义

    我们知道,端到端的状态一致性的实现,需要每一个组件都实现,对于Flink + Kafka的数据管道系统(Kafka进、Kafka出)而言,各组件怎样保证exactly-once语义呢?

    • 内部 —— 利用checkpoint机制,把状态存盘,发生故障的时候可以恢复,保证内部的状态一致性
    • source —— kafka consumer作为source,可以将偏移量保存下来,如果后续任务出现了故障,恢复的时候可以由连接器重置偏移量,重新消费数据,保证一致性
    • sink —— kafka producer作为sink,采用两阶段提交 sink,需要实现一个 TwoPhaseCommitSinkFunction

    Flink由JobManager协调各个TaskManager进行checkpoint存储,checkpoint保存在 StateBackend中,默认StateBackend是内存级的,也可以改为文件级的进行持久化保存。

    当 checkpoint 启动时,JobManager 会将检查点分界线(barrier)注入数据流;barrier会在算子间传递下去。

    每个算子会对当前的状态做个快照,保存到状态后端。对于source任务而言,就会把当前的offset作为状态保存起来。下次从checkpoint恢复时,source任务可以重新提交偏移量,从上次保存的位置开始重新消费数据。

    每个内部的 transform 任务遇到 barrier 时,都会把状态存到 checkpoint 里。

    sink 任务首先把数据写入外部 kafka,这些数据都属于预提交的事务(还不能被消费);当遇到 barrier 时,把状态保存到状态后端,并开启新的预提交事务。

    当所有算子任务的快照完成,也就是这次的 checkpoint 完成时,JobManager 会向所有任务发通知,确认这次 checkpoint 完成。

    当sink 任务收到确认通知,就会正式提交之前的事务,kafka 中未确认的数据就改为“已确认”,数据就真正可以被消费了。

    执行过程实际上是一个两段式提交,每个算子执行完成,会进行“预提交”,直到执行完sink操作,会发起“确认提交”,如果执行失败,预提交会放弃掉。

    具体的两阶段提交步骤总结如下:

    (1)第一条数据来了之后,开启一个Kafka的事务(Transaction),正常写入Kafka分区日志,但是标记未提交,这就是“预提交”

    (2)JobManager触发checkpoint操作,barrier从source开始向下传递,遇到barrier的算子将状态存入状态后端,并通知JobManager

    (3)Sink连机器收到barrier,保存当前状态,存入checkpoint,通知JobManager,并开启下一阶段的事务,用于提交下一个检查点的数据

    (4)JobManager收到所有任务的通知,发出确认信息,表示checkpoint完成

    (5)sink任务收到JobManager的确认信息,正式提交这段时间的数据

    (6)外部Kafka关闭事务,提交的数据可以正常消费

    以下来自:官网:end-to-end-exactly-once-apache-flink

    Let’s discuss how to extend a TwoPhaseCommitSinkFunction on a simple file-based example. We need to implement only four methods and present their implementations for an exactly-once file sink:

    1. beginTransaction - to begin the transaction, we create a temporary file in a temporary directory on our destination file system. Subsequently, we can write data to this file as we process it.
    2. preCommit - on pre-commit, we flush the file, close it, and never write to it again. We’ll also start a new transaction for any subsequent writes that belong to the next checkpoint.
    3. commit - on commit, we atomically move the pre-committed file to the actual destination directory. Please note that this increases the latency in the visibility of the output data.
    4. abort - on abort, we delete the temporary file.
    展开全文
  • C++ 检查内存泄露工具

    万次阅读 2021-02-23 15:08:07
    cppcheck (推荐):Cppcheck 是一种 C/C++ 代码缺陷静态检查工具。不同于 C/C++ 编译器及很多其它分析工具,它不检查代码中的语法错误。Cppcheck 只检查编译器检查不出来的 bug 类型,其目的是检查代码中真正的错误...
  • LoadRunner(五):检查

    千次阅读 2019-04-27 13:36:21
    文本检查点:web_reg_find()函数 方式一:手动输入检查点函数 方式二:在录制的时候生成检查点函数 图片检查点:web_image_check函数 参考链接: 前言 VuGen是根据服务器端返回的状态码来判断脚本是否执行成功...
  • 各种软件开发评审检查

    热门讨论 2011-01-06 11:43:07
    软件开发涉及的各种检查表 1.项目计划检查表 2.需求规格说明书检查表 3.概要设计说明书检查表 4.详细设计说明书检查表 5.编码检查表 6.测试用例检查表 7.产品验收和发布检查
  • 使用Hyper-V检查

    千次阅读 2019-12-10 07:13:45
    虚拟机检查点允许您捕获正在运行的虚拟机的状态,数据和硬件配置,以前称为虚拟机快照。在本文中,我们将讨论检查点,Hyper-V中可用的检查点类型以及如何使用检查点。 在Windows Server 2012 R2之前,没有检查点...
  • 健康检查

    千次阅读 2019-06-04 23:24:25
    序言没有见过极致的黑暗,就不知道什么是真正的光明。技术的作用是什么呢?技术就是让你吹醉到一个忘我的领域,然后能提起很大的兴趣。健康检查 健康检查分为...
  • AD中PCB检查设计错误规则设置(DRC检查配置)

    万次阅读 多人点赞 2019-11-07 09:48:26
    AD中PCB检查设计错误规则设置 遇到的问题:在设计好的PCB电路中,我们不能保证所有的线是否一次性全部布好,此时我们一般情况下需要设置电路的布线规则检查,以确保电路在布线的时候不会发生错误,下面我将向大家...
  • 7款英文语法检查工具推荐

    千次阅读 2021-07-24 06:13:27
    7款英文语法检查工具推荐 我们在使用英文写作或交流时,有时因为不够熟悉,会出现一些单词或者语法的错误,虽然可能不影响理解,但是会显得我们不够认真,所以语法检查是很有必要的,不过每次都逐句分析和改正是很...
  • Angular2 脏检查过程

    千次阅读 2017-05-01 16:49:06
    Angular 在脏检查的过程中到底做了哪些事呢?zone.js想要将数据变化应用到页面上面,首先需要检测数据的变化,那么数据会在什么情况下发生变化呢?数据变化一般发生异步事件中,例如: - 浏览器事件,例如 click, ...
  • Nacos健康检查

    千次阅读 2020-11-14 20:43:13
    一、健康检查流程图 二、客户端 nacos是如何定时通过心跳机制判断实例是否存活的呢,这就是健康检查机制。 NamingService.registerInstance()方法中,会做两件事情 组装心跳包BeatInfo,并且发送心跳 注册...
  • MySQL检查约束

    千次阅读 2020-03-13 16:55:30
    MySQL 检查约束(CHECK)可以通过 CREATE TABLE 或 ALTER TABLE 语句实现,根据用户实际的完整性要求来定义。它可以分别对列或表实施 CHECK 约束。 选取设置检查约束的字段 检查约束使用 CHECK 关键字,具体的语法...
  • 本次对初始工厂检查做进一步分析说明。本章内容主要参考密码行业标准。 GM/T 0065-2019 《商用密码产品生产和保障能力建设规范》 GM/T 0066-2019 《商用密码产品生产和保障能力建设实施指南》 Q1. 哪些企业需要审查...
  • 边界检查

    千次阅读 2017-07-11 15:08:42
    边界检查在程序设计中是指在使用某一个变量前,用来检查该变量是否处在一个特定范围之内的过程。最常见的是数组的下标检查,来防止下标超出数组的范围而覆盖其他的数据 由于每次都进行边界检查非常耗时,而且有些...
  • Docker 容器健康检查

    万次阅读 2021-01-21 11:20:33
    Docker 容器健康检查指的是在 Dockerfile 中使用 HEALTHCHECK 指令对容器的运行状态进行检查, 并在 docker ps 的 STATUS 栏显示 healthy/unhealthy。 HEALTHCHECK 指令有两种格式: HEALTHCHECK [OPTIONS] CMD ...
  • Oralce健康监控及健康检查Oracle数据库包括一个名为Health Monitor的框架,用于运行诊断检查数据库的各种组件。Oracle健康监视器检查各种组件数据库,包括文件,内存,事务完整性,元数据和进程使用。在检查器运行后...
  • Oracle迁移前环境检查

    千次阅读 2021-03-07 13:49:48
    查询无效对象 SELECT OWNER, OBJECT_NAME, OBJECT_TYPE FROM DBA_OBJECTS ...检查无效索引 SELECT OWNER, INDEX_NAME, STATUS FROM DBA_INDEXES WHERE STATUS <>'VALID' ORDER BY 1,2; 外部表检查 SELECT DISTI
  • nginx upstream 健康检查

    千次阅读 2019-05-28 19:10:46
    nginx upstream健康检查 使用 nginx_upstream_check_module 模块来对来专门提供负载均衡器内节点的健康检查的,这个模块是淘宝开发的,在tengine中这个模块是默认自带的,这个模块的作用就是用来检测后端realserver...
  • vs2010内存泄露检查工具

    千次下载 热门讨论 2012-05-16 21:42:26
    vs2010的c++内存泄露检查工具,可定位到出错代码行、开源免费工具。
  • Java单例模式中双重检查

    万次阅读 2018-08-01 11:38:29
    在努力创建更有效的代码时,Java 程序员们创建了双重检查锁定习语,将其和单例创建模式一起使用,从而限制同步代码量。然而,由于一些不太常见的 Java 内存模型细节的原因,并不能保证这个双重检查...
  • ORACLE-检查约束(check)

    千次阅读 2019-03-27 15:38:26
    ORACLE-检查约束(check) 1.检查约束 ( check )  某列取值范围限制、格式限制等 2.检查只能是男或者女 create table test29( id number primary key, sex varchar2(2) check(sex in (‘男,女’)) ); create table...
  • PCB学习笔记——DRC检查

    万次阅读 2019-03-23 22:41:13
    https://seujxh.wordpress.com/2018/05/08/drc检查/
  • 一,IntelliJ 代码检查IntelliJ IDEA的具有强大,快速,灵活的静态代码分析。它可以检测编译器和运行时错误,提出改进和完善,甚至在编译之前。 代码检查基础(Code analysis basics)IntelliJ IDEA的具有强大,...
  • ALLEGRO DRC检查

    万次阅读 2018-10-26 13:53:20
    PCB单项检查:Tools --&gt; Quick Reports 1,Unconnected Pins Report 2, Unplaced Components Report 3, Design Rules Check(DRC) Report 等。 敷铜检查: Shape---&gt; Glo...
  • 需要从群文件下载一个压缩包文件,可是却显示下载失败,具体原因为“QQ群文件未通过安全检查,禁止下载该文件”,按有的说法在设置里把安全防护的等级设置为最低,还是不行,手机也同样。在将放弃的时候,发现直接用...
  • TCPSocketAction案例 与容器内的localhost:80建立TCP连接进行监控检查: apiVersion: v1 kind: Pod metadata: name: pod-with-healthcheck spec: containers: - name: nginx image: nginx ports: - containerPort: ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,746,450
精华内容 1,498,580
关键字:

检查