去年11月，Amazon RDS推出的新的形态：Multi-AZ Cluster（三可用区三节点）。相比“原来的多AZ”（两个可用区）架构，新的Cluster模式是三节点架构，提供了更低的事务延迟，同时有更好的读扩展能力。国内的云厂商中，阿里云和腾讯云很早就有了三节点形态，一起看看，他们有哪些异同，在实际的业务场景中，哪些情况可以选择这种形态。

AWS RDS三节点（Multi-AZ Cluster）是什么？

这里将其主要特点概括如下：

• 这是一种3*AZ部署模式，而原来的Multi-AZ是2AZ部署或者单AZ部署。
• 使用了数据库的逻辑复制，而原来的双AZ使用的是EBS层的复制，这就使得Cluster的副本节点都可以直接提供读能力，有更好的读扩展能力。
• 使用了类似MySQL半同步的复制技术，事务日志网络到达其中任意一个副本主节点事务就可以提交，所以主节点上的事务延迟会降低，性能会提升（对比基于EBS的两节点）。
• 支持Graviton 2的规格和NVMe-based SSD存储，可以提供更好的性能。
• 同时支持MySQL和PostgreSQL两个引擎。

与阿里云、腾讯云数据库三节点的区别

阿里云RDS提供的“三节点企业版”，支持MySQL引擎，通过Paxos协议（或其变种）同步。相比Amazon的方案，其中一个节点使用了日志存储，成本可以更低；三个节点，只有一个节点提供服务。腾讯云MySQL也支持三节点版本，使用了半同步复制，可以选择异步、半同步或者强同步三种模式，也只有一个节点可以提供服务。

相比AWS，阿里云与腾讯云的三节点模式都可以由用户自由选择可用区分布，即可以都在一个可用区，也可以分布在两个或三个可用区，给了客户更强的灵活性。

(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)：参考

注：这是一篇阿里云数据库ACP认证的软文，但是还是非常非常推荐阅读。因为这个认证很可能会成为国内数据库领域最重要的认证，对很多数据库极其相关技术人员都会有很大的影响。

概述

TLDR版本：阿里云数据库ACP认证填补了云时代与传统数据架构时代之间数据库专业认证的空白。无论是不是写软文，笔者都是非常推荐云数据库从业者或者与数据库相关度比较高的开发者，都去拿下这个认证的。另外，也提醒一下，这个认证是刚刚推出，无论是试题还是流程都还有一些小的磕盼，也可以考虑等半年之后再去拿证，都时候应该会更加成熟一些。也预警一下：这个证书要花费一些费用，考试难度还是比较大的，所以通过考试并不容易，笔者考试过程整整鏖战两小时，83分，涉险过关（80分通过）。

什么是阿里云数据库ACP认证

我从阿里云出来已经几个月了，恍如隔世…，出来之前也曾是阿里云数据库认证体系建设的负责人，在整个事业部的支持下，设计并上线了阿里云数据库的ACA认证（参考）。在上周，阿里云数据库推出ACP认证，是一个更高级别的认证，认证一上线，我就便迫不及待的上线去考下了这个证书。据说，可能是全球第一个获得阿里云数据库ACP认证的人员（烦请内部同学再帮确认一下）。

数据库ACP认证是整个阿里云面向开发者的认证体系的一部分（参考），与初级的”数据库ACA”认证组成了数据库垂直领域的初步认证体系。ACP全称是专业工程师(Alibaba Cloud Certified Professional)，也是*当前*云数据库最高端的认证（也许未来会推出ACE）。主要面向，云数据库相关从业者，包括DBA、云系统管理员、与数据库相关度比较高的开发者等。要求上，需要参与认证的人，对通用数据库基础有非常好的了解，同时，对于云数据库相关技术也非常详细的了解。数据库的ACP认证分了两个方向：关系型数据库、数据仓库，可以根据自己的专业背景选择其中一个方向去挑战。

数据库领域的”各种认证”

在计算机发展之初，一个重要的应用就是数据的存储与计算。数据库在过去60年的发展中，一直都是计算机技术最重要的分支技术之一。在现代数字化企业架构中，数据架构的设计、数据技术选型都是重大的挑战，无论是在基于本地IDC的架构，还是基于现代的云计算架构，这一点都没有发生变化。而且，在当前各行各业数字化转型的过程中，数据架构在企业中的地位也越来越重要。

数据库技术人员也一直是构建企业数据架构的核心人员。在数据库技术发展的过去的半个世纪，各个数据库厂商，为了培养各个不同类型的数据库的专业人才，推出了各个垂直方向的认证，例如，Oracle的OCP、OCM认证，微软早期的MCSA、MCSE、MongoDB Developer/Database Administrator、TiDB的Associate/professional、OceanBase的OBCA/OBCA/OBCE等。

这些认证中，其中Oracle认证一度最为成功。从认证的设计上，非常完善，OCA/OCP/OCM三级认证，层层递进，很好的帮助学习逐步了解Oracle数据库的各个方面。另外，更重要的，也因为Oracle认证的权威性，企业人员在招聘时有了一个不错的参考，也让想进入这个领域的从业者，有了一个非常好的入门途径（参考）。

• 

• 

• 

• 

云时代数据库从业者的新要求

云计算已经改变了企业和开发者使用数据库的方式，现代企业是以数字化为基础的，数据架构也是企业架构的核心部分，企业在数据架构选型上，两个趋势已经是事实了：一个是”云化”，选择以云计算技术为基础的架构，利用云计算的平台与产品优势，提升企业的业务研发效率；一个是”多种数据库”并行，随着数字化在业务场景中不断深化，各类的数据场景都呈现出了不一样的数据存储、查询、分析的要求，一两个数据库就解决所有的企业存储要求，已经不可能了。可以看到，在传统关系型数据库基础上，图数据库、时序数据库、文档数据库等都在快速发展。

随着云计算的逐渐渗透，各家云厂商争相发布的各个数据库全托管服务(如RDS)，使得企业内部已经不再需要单独的人去做很多基础的工作了，例如数据库的安装部署、备份管理、监控配置等；另一方面，随着数据存储场景的增加，数据库种类的增多，如何选择最合适的数据库存储引擎支撑业务快速发展与决策，成为了更重要的命题；另外，随着云厂商的积极投入(“juan”，第三声)，如何选择最适合企业的云数据架构，也是企业的基本诉求。

这对企业数据库架构师、数据库管理员就提出了完全不同的要求，无论是技能上，还是职业发展上，都发生了很大的变化。这也是为什么传统的认证，已经不再适应当前的时代，细心的数据库从业者应该已经注意到了这一点，一方面传统的认证参与人员变少了，另一方面各个数据库厂商自己认证也在变化（例如Oracle将废弃老的OCA，微软也重点推Azure相关的认证）。

在多个云厂商并驾齐驱的时代，在数据库存储引擎百花齐放的时代，云数据库的认证就成为当前的最佳选择，云数据库认证将在众多的数据库认证中崛起。这也是云时代，对数据库从业者的新要求：熟悉多种数据库引擎、熟悉多个云平台上的数据库特点，基于此构建现代企业的数字化架构，帮助企业提升业务效率与决策支持。

云厂商数据库认证的优势与缺点

相比单个数据库认证，云数据库厂商的认证则更加丰富，更加立体，不是简单拘泥于某个数据库的技术细节，更加在意数据库的通用技术，例如阿里云数据库ACP认证就覆盖了MySQL、PostgreSQL、数据复制工具等产品。当然，”私心”也很明显，例如，就包含了大量的PolarDB、AliSQL等相关内容。当然，阿里云作为重要的数据库厂商，PolarDB又是最重要的产品，多去了解一下，也是非常有必要的。

谁应该考ACP

数据库的ACP认证难度系数是比较高的，并不适合所有的技术人员都去考。有几类人是建议获取这个认证的：

• 所有的DBA、数据架构师
• 构建数据相关应用的开发人员
• 基于云架构的系统管理员
• 想深入了解云数据库技术的技术人员

考试的形式与内容

这部分，在官网上有比较详细的说明：参考。这里简单说一下感受，目前，学习资料还不是很丰富，有一个200页的ppt，内容大致方向都涵盖了，但是实际考试试题是远超出ppt本身的内容的，ACP考试配套的还有一个视频学习课程，如果想顺利通过考试，认真学习视频是非常有必要的。另外，除了考试之外，还有一系列的动手试验，目前，这部分设计的都还比较简单，也都有step by step的引导，难度还不算高。

完成动手实验，通过考试，就可以获得正式的ACP证书了。

最后，也晒一下，据悉是全球第一个阿里云数据库ACP的证书，如下：

参考文档

1. Database@Wikiedia https://en.wikipedia.org/wiki/Database#History
2. 阿里云数据库ACA认证： https://edu.aliyun.com/certification/aca09
3. 阿里云数据库ACP认证：https://edu.aliyun.com/certification/acp17
4. 阿里云认证： https://edu.aliyun.com/certification
5. Oracle数据库认证： https://education.oracle.com/en/oracle-certification-path/pFamily_32
6. PingCAP认证： https://learn.pingcap.com/learner/certification-center

这个示例可以结合着之前的连接MySQL一起来看：参考。

代码如下。当然，运行之前，你需要

• 已经完成了基本的工具安装，这个并不容易（参考）
• 已经有一个可以正常运行的与连接的SQL Server
• 已经有一个网络上到SQL Server联通的主机的ssh账号
• 下面的实例中，还需要一个t_1表，表中有三个字段

import pyodbc
import pandas as pd
import logging
import sshtunnel
from sshtunnel import SSHTunnelForwarder

ssh_host = 'x.x.x.x'
ssh_port=22
ssh_username = 'lilei'
ssh_password = 'xxxxxx'


db_server = 'x.x.x.x'
db_port= 1433
database = 'xxx'
db_username = 'xxx'
db_password = 'xx'


tunnel = SSHTunnelForwarder(
    (ssh_host, ssh_port),
    ssh_username = ssh_username,
    ssh_password = ssh_password,
    remote_bind_address = (db_server, db_port),
)
tunnel.start()


cnxn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER=127.0.0.1,'+str(tunnel.local_bind_port)+';DATABASE='+database+';UID='+db_username+';PWD='+ db_password)
cursor = cnxn.cursor()

cursor.execute("SELECT * FROM dbo.t_1;")
row = cursor.fetchone()
while row:
    print('ID: %(id)03s | nick: %(nick)012s | birthdate: %(bd)010s' %
      {'id':row[0],'nick':row[1],'bd':row[2]})
    row = cursor.fetchone()