Aurora自2014年发布以来，一直是AWS的最核心数据库产品，而Serverless则是这个产品最重要的功能之一了。在2018年08月，Serverless功能刚刚GA，当时做过一次测试（参考）。在2020年底的re:Invent上，Andy Jassy宣布Aurora发布Serverless v2，时隔一年半，终于GA，一起来看看实际效果怎样吧。

在最近看到该功能的介绍文章中，使用了”几分之一秒内扩展”、” scales instantly and nondisruptively “等描述，对此，我是保持怀疑的，这也要实测一下的原因，从一个用户感受的角度，看看一次升级(scaling)需要多长时间。

测试结果概述

• 在这次实际测试中，新的Serverless v2，可以将scaling up的时间降低到10秒级别。系统压力上来后，首次升级(scaling up)花了13秒，之后的几次升级分别花了7秒、4秒、10秒等。在这几秒内，Aurora需要完成监控采集、分析与决策，变配动作完成等动作。于用户侧，系统压力突增时，10秒内Aurora就会完成升级，这是非常实用和强大的。
• 相比4年前GA版本数分钟级别的升级(scaling)，新的版本提升非常大。不过，与宣传的亚秒级( in a fraction of a second )还有差距的。当然，一种猜测是，”亚秒内”完成的是变配动作本身，不包括监控、决策与命令下发等过程。
• Scaling down是逐步阶梯式完成的，每次间隔约1分钟，这是符合预期的。
• 新的版本与旧版本有非常好的兼容性，可以作为旧版本的replica，然后切换为主节点，也就可以完成平滑的升级。新的版本，支持MySQL 8.0和PostgreSQL 13版本。
• 该功能的客户价值是非常明显的：在更多的业务场景中，可以帮助用户降低成本，同时也可以帮助应对更多的突发流量。另外，云计算的”使命”之一是通过统一的底层资源调度，提升资源利用率，降低资源使用成本，而该功能，在交易数据库的场景，把这个”使命”的粒度降低到了”秒”级别。用好了该功能，在很多场景中，降低50%的数据库成本应该是容易的。

(more…)

SQL Server的用户体系和MySQL有非常大的不同，无论是在使用上、还是概念上。所以，这里梳理一下SQL Server的用户与认证的一些基础概念与使用。另外，这个概念在SQL Server相关资料中各个地方都会出现，是理解权限体系的基础。

“login”与“database user”

在SQL Server中，”login”不是一个动词，而是一个”名称”（注：”log in”是动词），代表的是一个用于登录的对象（Object），这是一个服务器级别的对象，所以，它有自己的登录名(login name)、密码、默认语言、认证方式等。需要强调的是，它不是一个数据库（database）级别的对象。

而”Database User”是一个数据库级别的对象，与之相对应的则是数据库级别的权限。”Database User”并不能连接或者登录SQL Server实例，所以，一般来说，也不需要密码。

“login”因为是Server级别的，所以权限也都是Server级别的。本身不能赋予任何数据库相关的权限，但是，login可以和一个Database User建立映射，使用该login连接数据库的时候，该连接也就可以根据Database User权限进行相关的操作了。

最常见、最简单的创建login和database user的命令如下：

  use zzxdb2;
  create table t_1(id int,nick nchar(12),birthday date);

  create login zzxdb2 with password='zzxdb2' ,CHECK_POLICY=OFF;
  create user zzxdb2 for login zzxdb2;

  -- 当没有赋予权限的时候，zzxdb2可以登录SQL Server，但是看不到zzxdb2下面的TABLE
  -- 所以，最后还需要赋予database user相应的权限，如下
  exec sp_addrolemember 'db_owner', 'zzxdb2'; 

为什么容易混淆

通常的系统中只有用户的概念，权限系统都是基于用户。而SQL Server在其上新增了Login这一层，与其他的系统都不同。另外，在一般的客户端中，在需要登录的时候，通常都是使用”user name”/”password”作为登录认证的凭证，而不是”Login”/”password”，所以初学者通常容易混淆，例如微软的Mac客户端Azure Data Studio：

一些可以帮助理解”login”和”user”关系的一些问题

1. 只创建login，而不map到一个具体的database用户，是否可以登录？

答案是简单的：可以登录，但是没有数据库相关的权限。测试如下：

先创建一个没有映射到”user”的”login”：

CREATE LOGIN alogin WITH PASSWORD = 'alogin', CHECK_POLICY=OFF;
-- 注： CHECK_POLICY可以让你设置简单密码，并不建议加上

• 使用上面的”login”在Azure Data Studio中连接并进入SQL Server。可以看到，可以正常登录，但是因为没有database相关的权限，所以展示database里面的对象的时候，会失败，如下：

也就说，”login”只有在与具体的某个database user建立了mapping之后，才可以访问对应的数据库。在上面例子中的”login”主体”alogin”，要访问和管理数据库9zcloud，是会失败的。

当然，如果真的需要访问的话，那么我们需要先建一个database user，并在user和login之间建立mapping，具体操作如下：

CREATE USER a_db_user_9zcloud FOR LOGIN alogin;  

2. 创建用户，不映射到任何login，后续是否还可以重新映射？

如果在用户创建的时候显式的声明，不映射到任何login，那么后续是否还可以重新映射到某个login？答案似乎没有那么明显了。遂测试如下：

CREATE USER a_db_user_9zcloud WITHOUT LOGIN;
ALTER USER  a_db_user_9zcloud WITH LOGIN='alogin';
-- 报错如下：

消息 33016，级别 16，状态 1，第 45 行
The user cannot be remapped to a login. Remapping can only be done for users that were mapped to Windows or SQL logins.

可见，如果在创建的时候显示声明不映射到任何”login”，那么就不能够再重新映射任何的”login”。

3. 如果用户名和login主体名字不一样，客户端登录的时候使用哪个？

答案是显然的，但是还是验证一下。

具体的，如果数据库用户名和login用户名不一样，那么在登录连接SQL Server的时候，使用的是database user还是login的名称？具体看下面的例子，在使用客户端登录的时候，使用的alogin，还是使用a_db_user_9zcloud？

CREATE LOGIN alogin WITH PASSWORD = 'alogin', CHECK_POLICY=OFF;
CREATE USER a_db_user_9zcloud FOR LOGIN alogin;

答案，当然是使用login的主体alogin。

4. 在创建用户时如果映射到了某个login，同时也创建密码，那么这个密码有什么用？

是啊，有什么用呢？ 具体的，在创建用户时映射到某个具体的login，但是依旧指定一个密码，那么这个密码有什么用？测试验证如下：

CREATE LOGIN alogin WITH PASSWORD = 'alogin', CHECK_POLICY=OFF;
CREATE USER a_db_user_9zcloud FOR LOGIN alogin WITH PASSWORD = 'dbuser9zcloud';

答案：你就不能这么用！！（注：仅当在contained database中可以使用密码，参考） 在明确映射到某个具体的login的用户，不需要密码，也无法指定密码。所以，上面的语句执行会失败，报如下错误：

消息 33234，级别 16，状态 1，第 47 行

The parameter PASSWORD cannot be provided for users that cannot authenticate in a database.

另外，注意到login在创建的时候，是可以指定默认数据库(DEFAULT_DATABASE)的；创建用户的时候，可以指定默认的schema。

其他内容

• 在给一个对象(主体)赋权的时候，可以通过按照细粒度(某个表的某种权限)方式进行，也可以直接将其加入到某个角色组，那么这个角色组对应的权限就都有了。例如，将login加入到”sysadmin”(fixed server role)，那么就有了所有sysadmin角色组的权限，sysadmin可以理解是一个超级权限组，如果在该组中，那么访问对象时不需要检查该账号的权限；与sysadmin对应的一个权限是”CONTROL SERVER”，如果使用GRANT则可以使用这个权限。
• 另外，前文中偶尔会用到”主体”这个名称，英文对应SQL Server文档中的”Principals”，”主体”是SQL Server官方中文文档的翻译(参考)。可以理解为一个实体，或者前面对象的实例化或者实体，也就是说，某个具体的”server roles, logins, database roles, or users.” 都可以称作”Principals”。
• SQL Server中的系统表sys.server_principals、sys.server_permissions会存储相关的元数据。
• 在SQL Server官方文档中将”login”翻译为”登录名”(参考)。这也是为什么，一些客户端在让输入用户名的时候，其实是输入一个login主体名和对应的密码。
• 在创建user的时候，如果没有显示的指定FOR LOGIN，没有指定WITHOUT LOGIN，那么该user将会被映射到同名的login上(还没有验证这一点，参考：If FOR LOGIN is omitted, the new database user will be mapped to the SQL Server login with the same name.)。
• 另外，系统中还有一个名字为guest的login，默认是不可用的。
• 在实际中，也有一些场景是需要创建user，而不映射到任何的login，后续会再考虑介绍这类场景。

参考阅读

• Determining Effective Database Engine Permissions：链接 如何查看系统中的账号权限
• Database Engine Permissions SQL Server 2017 and Azure SQL Database： 链接

这是一个记录。虽然微软的文档已经非常完善和友好了，但是涉及到一些软件版本等相关问题，配置并不畅通。

安装

本地环境是macOS Big Sur 11.4版本，使用的是Python 3.8.2版本。

zzx@localhost % python3
Python 3.8.2 (default, Apr  8 2021, 23:19:18)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

需要安装pyodbc、unixodbc、msodbcsql17、mssql-tools等工具（详细参考）：

pip3 install pyodbc
brew install unixodbc

测试脚本

主要参考微软文档：Proof of concept connecting to SQL using pyodbc。测试连接脚本如下：

import pyodbc
# Some other example server values are
# server = 'localhost\sqlexpress' # for a named instance
# server = 'myserver,port' # to specify an alternate port
server = 'x.x.x.x'
# server = 'tcp:x.x.x.x,1433'
database = 'xxx'
username = 'xxx'
password = 'xxx'
cnxn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password)
cursor = cnxn.cursor()

#Sample select query
cursor.execute("SELECT @@version;")
row = cursor.fetchone()
while row:
    print(row[0])
    row = cursor.fetchone()

一下子就跑通了？ 有经验的开发者都知道，那当然不能这么顺利，是吧。首先，遇到如下报错：

Traceback (most recent call last):
  File "mssqlremotessh.py", line 10, in <module>
    cnxn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password)
pyodbc.OperationalError: ('08001', '[08001] [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection (0) (SQLDriverConnect)')

是哪个环节的问题？

老实说，这个报错真的很不友好，无法看出来是什么地方的问题。首先，根据Github上一个issue建议首先通过isql命令（应该是unixODBC的工具）尝试连接一下SQL Server，果然有了新的发现：

# 注意：下面命令的IP和密码都被修改了
isql -v -k 'Driver={ODBC Driver 17 for SQL Server};Server=tcp:18.336.80.202,1433;Database=9zcloud;Uid=zzx;Pwd=********;'


[08001][Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: [OpenSSL library could not be loaded, make sure OpenSSL 1.0 or 1.1 is installed]
[08001][Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection
[ISQL]ERROR: Could not SQLDriverConnect

解决openssl版本依赖问题

看起来似乎是ODBC依赖OpenSSL 1.0或者1.1，而查看了本地默认安装的应该是v3版本，查看如下：

$ cd /usr/local/Cellar/ && ls
$ cd openssl@3/3.0.1/bin
$ ./openssl version
$ OpenSSL 3.0.1 14 Dec 2021 (Library: OpenSSL 3.0.1 14 Dec 2021)

自此，已经找到了问题的症结（也可能是问题的症结之一，是吧）：似乎是ODBC只认这两个版本的openssl，沿着此线索搜索，发现，这个问题在Github的 issue 59@microsoft/homebrew-mssql-release 中讨论得比较多，而且，在下面的回答中也有一些办法可以尝试解决：在系统中，额外在安装openssl 1.1，并把链接库目录的软连接从3.0版本更换到1.1版本。（这么做，还是有点担心其他的软件运行有问题的，但是先这么做吧，把问题解决了），详细回答参考如下：

具体的操作如下：

zzx@localhost ~ % ls -lah /usr/local/opt/openssl
lrwxr-xr-x  1 zzx  admin    25B 12 28 10:21 /usr/local/opt/openssl -> ../Cellar/openssl@3/3.0.1

unlink /usr/local/opt/openssl

# 这里要注意，你所安装的openssl版本和目录可能和以上截图中是不同的，所以要根据实际情况进行连接，例如我这里是1.1.1m版本，而不是截图中的1.1.1l版本。
ln -s /usr/local/Cellar/openssl@1.1/1.1.1m /usr/local/opt/openssl

Finnally，it works！！

zzx@localhost ~ % ln -s /usr/local/Cellar/openssl@1.1/1.1.1m /usr/local/opt/openssl
zzx@localhost ~ % isql -v -k 'Driver={ODBC Driver 17 for SQL Server};Server=tcp:19.36.80.2,1433;Database=9zcloud;Uid=zzx;Pwd=******;'
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL> select * from dbo.t_1;
+------------+---------------------------------+-----------+
| id         | nick                            | birthday  |
+------------+---------------------------------+-----------+
| 1          |                                 |           |
| 2          | zzx                             |           |
| 3          | yzs                             | 2008-09-23|
+------------+---------------------------------+-----------+

在回头去运行，最前面的示例脚本，也可以正常连接SQL Server，至此，剧终。所以，回头来看，今天的解决问题的堆栈如下：

• unixODBC关于openssl版本兼容性的问题
• 安装unixODBC & mssql-tools
• 尝试python连接SQL Server
• 尝试通过ssh tunnel连接SQL Server

相关阅读

• 更多关于什么是unixODBC，什么事isql，可以参考：unixODBC
• Install the Microsoft ODBC driver for SQL Server (macOS)：参考