ChatGPT现在科技界最热门的话题。一个故事说ChatGPT已通过谷歌的3级编程面试。我想知道,这是否意味着ChatGPT准备取代MySQL dba,吗?不。让我告诉你为什么。
最近,我们的一个客户正在考虑使用Percona基于文件的加密数据静止密匙环插件。雷竞技下载官网使过程更加安全,他们认为删除本地keyring_file MySQL后开始。所以即使有人主机访问、数据文件仍然受到保护,因为他们没有访问主密钥用于加密的密钥表运行加密在休息的时候。
让ChatGPT在MySQL管理
让我们看看ChatGPT会说。
我问ChatGPT这个问题:“C一次我们备份,然后删除keyring文件用于加密MySQL开始后静止插件吗?”
从ChatGPT答案:”不,这不是建议删除keyring文件用于加密静止MySQL运行时插件,这可能会导致数据损坏或异常行为。keyring文件加密静止插件的一个重要组成部分,用于安全地存储加密的信息,比如密码和其他敏感数据。
安全到keyring文件进行更改,建议停止MySQL服务,备份文件,然后进行任何必要的修改或删除。一旦改变了,你可以再次启动服务。
未能进行更改之前,停止MySQL服务keyring文件可能导致数据丢失或者腐败,它不可能恢复数据。以确保数据的安全性和完整性,重要的是遵守推荐程序停止服务,备份文件,并做出任何必要的改变。”
正确答案看起来很乍一看,似乎很合理,如果你没有足够的工作经验在Percona基于文件的密匙环的插件。雷竞技下载官网事实上,答案是只是部分正确,甚至完全错误的在很多地方。
首先,我们可以删除keyring文件用于加密静止MySQL运行时插件。插件仍正常工作,加密一个新表,解密加密的表的内容,没有腐败,或意想不到的行为。
这是因为密匙环插件在启动时加载的整个内容keyring_file(即。,关键id, key user, key type, together with keys themselves) into the cache, unless MySQL is restarted, or you want to rotate the master key (you won’t though, as you know you have removed the keyring_file), it will not need the keyring file anymore. We can verify that through the following example:
- 我们开始MySQL配置”early-plugin-load = keyring_file。所以和keyring_file_data = / var / lib / mysql / keyring_file“启用Keyring_file插件。MySQL开始时,它创建了一个空文件/var/lib/mysql/keyring_file。然而,当我们创建一个表使用加密= ' Y ',我们可以看到文件/var/lib/mysql/keyring_file不是空了。这是因为Keyring_file插件创建了一个主密钥将所有记忆中的信息和数据的备份保存到文件/var/lib/mysql/keyring_file。
|
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
|
ec2- - - - - -
用户@ip- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年美元~)猫/等/my.cnf
#加密在休息
早期- - - - - -插件- - - - - -
负载
=keyring_file.so
keyring_file_data = / var/自由/mysql/keyring_file
mysql>
创建
数据库
测试;
mysql>
显示
创建
模式
testG
* * * * * * * * * * * * * * * * * * * * * * * * * * *1。
行
* * * * * * * * * * * * * * * * * * * * * * * * * * *
数据库:测试
创建
数据库:
创建
数据库
“测试”
/ * !40100默认的CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */
/ * !80016默认的加密=”N' */
(ec2- - - - - -
用户@ip- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年美元~)sudolslhr/ var/自由/mysql /
net -- - - - - -r - - -——1 mysql mysql 0 2月9日00:04 keyring_file
mysql>
使用
测试;
数据库
改变了
mysql>
创建
表
t1(c1
INT,
主键
pk (c1))加密=“Y”;
mysql>
插入
成
t1 (c1)
值(1);
mysql>
选择
*
从
t1;
+ - - - +
|c1|
+ - - - +
|1|
+ - - - +
mysql>
显示
创建
表
t1G
* * * * * * * * * * * * * * * * * * * * * * * * * * *1。
行
* * * * * * * * * * * * * * * * * * * * * * * * * * *
表:t1
创建
表:
创建
表
“t1”(
“c1”
int
非空,
主键
(c1)
)
引擎
=
InnoDB
默认的
字符集
=utf8mb4
核对
=utf8mb4_0900_ai_ci加密=“Y”
(ec2- - - - - -
用户@ip- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年美元~)sudolslhr/ var/自由/mysql/keyring_file
net -- - - - - -r - - -mysql mysql——187 2月9日00:07 /var/lib/mysql/keyring_file
mysql>
显示
变量
就像
“% UUID %”;
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|Variable_name|
价值
|
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|server_uuid|ccdb4a6c- - - - - -9 c3b- - - - - -11艾德- - - - - -805 e- - - - - -0 a357402d413|
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
(ec2- - - - - -
用户@ip- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年美元~)sudo六世/ var/自由/mysql/keyring_file
00000000:4 b657972年696 e6720年6669年6 c652076年6572年密匙环
文件
版本
00000010:7369年6 f6e3 a322 e308000年0000年0000年0000年锡安:2.0 ........
00000020:3000年0000年0000年0000年0300年0000年0000年0000年0 ...............
00000030:0000年0000年0000年0000年2000年0000年0000年0000年...............
00000040:494 e4 e4f4442年4 b65792 d6363年6462年3461年INNODBKey- - - - - -ccdb4a
00000050:3663年2 d396333年622 d3131年6564年2 d383035年6摄氏度- - - - - -9 c3b- - - - - -11艾德- - - - - -805年
00000060:652 d3061年3335年3734年3032年6434年3133年2 d31e- - - - - -0 a357402d413- - - - - -1
00000070:4145年537 d7 c7fa42e8 e5a85 ff2301年cd95AES} | .... Z . .#……
00000080:d4b09 e67dd5c3 bfe1 cc777年e28 d22摊位57 e6g。…w . .“W。
00000090:bb60 c500 0000 0000 454 4691 068 e 5190 f。”……EOF……问。
000000 a0: d204 4689 90 8620 3022 80 fb af 4 b9d 1302 . . F . .0”.... K……
000000 b0:5 a7c84 bb华氏516度07年a8d1b69 a0aZ | . .问:……
|
- 我们然后删除备份文件keyring_file没有重新启动MySQL。MySQL仍然运行的很好,我们可以选择从加密的表,我们也可以创建一个新表加密= ' Y ';一切工作一样keyring_file之前删除了文件
|
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
|
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
mv
/var/自由/mysql/keyring_file
/var/自由/mysql/keyring_file_1
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
ls
- - - - - -lhr
/var/自由/mysql/keyring_file
ls
:
不能
访问
/var/自由/mysql/keyring_file
:
没有
这样的
文件
或
目录
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
ls
- - - - - -lhr
/var/自由/mysql/keyring_file_1
- - - - - -rw- - - - - -r- - - - - -
1
mysql
mysql
187年
2月
9
00
:
07年
/var/自由/mysql/keyring_file_1
mysql
>
选择
*
从
t1
;
+ - - - +
|
c1
|
+ - - - +
|
1
|
+ - - - +
mysql
>
创建
表
t2
(
c1
INT
,
主
关键
pk
(
c1
)
)
加密=“Y”
;
mysql
>
显示
创建
表
t2G
* * * * * * * * * * * * * * * * * * * * * * * * * * *
1。
行
* * * * * * * * * * * * * * * * * * * * * * * * * * *
表
:
t2
创建
表
:
创建
表
”
t2
”
(
”
c1
”
int
不
零
,
主
关键
(
”
c1
”
)
)
引擎=InnoDB
默认的
字符集=utf8mb4
核对=utf8mb4_0900_ai_ci
加密=“Y”
mysql
>
插入
成
t2
(
c1
)
值
(
2
)
;
mysql
>
选择
*
从
t2
;
+ - - - +
|
c1
|
+ - - - +
|
2
|
+ - - - +
|
- 我们重新启动MySQL,发现MySQL从错误开始抱怨“InnoDB找不到主密钥加密,请检查加载的密匙环。”。但它创建另一个空文件/var/lib/mysql/keyring_file后重新启动。现在,我们不能做任何操作加密的表上,因为它会报告错误,即使我们将备份文件复制/var/lib/mysql/keyring_file_1 /var/lib/mysql/keyring_file覆盖文件而不需要重新启动。
|
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
|
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
systemctl
停止
mysql
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
systemctl
开始
mysql
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
mysql
- - - - - -u
根
- - - - - -p
mysql
>
选择
*
从
t1
;
错误
3185年
(
HY000
)
:
可以”t
找到
主
关键
从
密匙环
,
请
检查
在
的
服务器
日志
如果
一个
密匙环
是
加载
和
初始化
成功
。
mysql
>
选择
*
从
t2
;
错误
3185年
(
HY000
)
:
可以”t
找到
主
关键
从
密匙环
,
请
检查
在
的
服务器
日志
如果
一个
密匙环
是
加载
和
初始化
成功
。
mysql
>
显示
创建
表
t1G
错误
3185年
(
HY000
)
:
可以”t
找到
主
关键
从
密匙环
,
请
检查
在
的
服务器
日志
如果
一个
密匙环
是
加载
和
初始化
成功
。
mysql
>
显示
创建
表
t2G
错误
3185年
(
HY000
)
:
可以”t
找到
主
关键
从
密匙环
,
请
检查
在
的
服务器
日志
如果
一个
密匙环
是
加载
和
初始化
成功
。
mysql
>
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
猫
/var/日志/mysqld
. log
。
。
。
2023年- - - - - -02- - - - - -09年t00
:
14
:
56.719139 z
1
(
错误
]
(
我的- - - - - -012657年
]
(
InnoDB
]
加密
可以”t
找到
主
关键
,
请
检查
的
密匙环
是
加载
。
2023年- - - - - -02- - - - - -09年t00
:
14
:
56.719170 z
1
(
错误
]
(
我的- - - - - -012226年
]
(
InnoDB
]
加密
信息
在
数据文件
:
。/测试/t1
.ibd
可以”t
是
解密
,
请
确认
那
密匙环
是
加载
。
2023年- - - - - -02- - - - - -09年t00
:
14
:
56.720098 z
1
(
错误
]
(
我的- - - - - -012657年
]
(
InnoDB
]
加密
可以”t
找到
主
关键
,
请
检查
的
密匙环
是
加载
。
2023年- - - - - -02- - - - - -09年t00
:
14
:
56.720117 z
1
(
错误
]
(
我的- - - - - -012226年
]
(
InnoDB
]
加密
信息
在
数据文件
:
。/测试/t2
.ibd
可以”t
是
解密
,
请
确认
那
密匙环
是
加载
。
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
ls
- - - - - -lhr
/var/自由/mysql/keyring_file
- - - - - -rw- - - - - -r- - - - - -
1
mysql
mysql
0
2月
9
00
:
14
/var/自由/mysql/keyring_file
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
mv
/var/自由/mysql/keyring_file_1
/var/自由/mysql/keyring_file
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
ls
- - - - - -lhr
/var/自由/mysql/keyring_file
- - - - - -rw- - - - - -r- - - - - -
1
mysql
mysql
187年
2月
9
00
:
07年
/var/自由/mysql/keyring_file
mysql
>
选择
*
从
t1
;
错误
3185年
(
HY000
)
:
可以”t
找到
主
关键
从
密匙环
,
请
检查
在
的
服务器
日志
如果
一个
密匙环
是
加载
和
初始化
成功
。
mysql
>
选择
*
从
t2
;
错误
3185年
(
HY000
)
:
可以”t
找到
主
关键
从
密匙环
,
请
检查
在
的
服务器
日志
如果
一个
密匙环
是
加载
和
初始化
成功
。
|
- 我们又重新启动MySQL,备份文件/var/lib/mysql/keyring_file_1 /var/lib/mysql/keyring_file覆盖文件。现在一切都恢复正常。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
systemctl
停止
mysql
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
sudo
systemctl
开始
mysql
(
ec2- - - - - -用户
@
知识产权- - - - - -172年- - - - - -31日- - - - - -32- - - - - -242年
~
]
美元
mysql
- - - - - -u
根
- - - - - -p
mysql
>
选择
*
从
t1
;
+ - - - +
|
c1
|
+ - - - +
|
1
|
+ - - - +
mysql
>
选择
*
从
t2
;
+ - - - +
|
c1
|
+ - - - +
|
2
|
+ - - - +
|
第二,我们不应该做任何更改到keyring文件。相反,我们应该通过插件,旋转的关键,我们需要备份在我们旋转的关键。然而,所提供的答案ChatGPT意味着我们可以做一些更改到keyring文件,这是非常错误的。
结论
ChatGPT可能只提供部分正确,或者更糟糕的是,完全错误的答案你的问题,仍然需要专家仔细检查正确性。相比于其他搜索引擎,提供可能的链接到你那道问题的答案,依靠专业知识看哪一个是有用的,和/或如何使用这些信息。你会为你的MySQL数据库有一个DBA无论ChatGPT和/或其他搜索引擎。
注::When I was done with the blog, I asked the ChatGPT again, and here was what I got:
问:“我们可以备份,然后删除keyring文件,用于加密静止的Percona插件,MySQL后开始?”雷竞技下载官网
ChatGPT:“是的,你可以备份,然后删除keyring文件Percona加密后静止插件使用的MySQL已经开始。雷竞技下载官网然而,删除加密的密匙环文件将导致损失数据,所以重要的是要确保你有备份加密密钥和有一个计划对密匙环之前删除的数据文件,以防止数据丢失或损坏。”
问:”我们可以备份和删除keyring文件用于加密MySQL开始后静止插件吗?”
ChatGPT:“是的,这是可能的备份和删除keyring文件用于加密后静止插件MySQL已经开始。然而,删除加密的密匙环文件将导致损失数据,所以重要的是备份加密密钥和有一个计划对密匙环之前删除的数据文件,以避免数据丢失或腐败。”
第二天,我又得到了另一个答案:
问:”我们可以备份和删除keyring文件,用于加密静止的Percona插件,MySQL后开始?”雷竞技下载官网
ChatGPT:”keyring文件静止Percona加密插件的一个重要组成部分,它用于安全地存储加密密钥。雷竞技下载官网之前备份keyring文件删除,将确保你有一个加密密钥的副本,并将在必要时能够恢复它们。然而,消除keyring文件MySQL运行时不推荐,因为它可能会导致意想不到的行为或数据损坏。重要的是停止MySQL和备份keyring文件之前删除它以避免任何潜在的问题。”
所以,ChatGPT可能给同样的问题在不同的时间不同的答案。它让ChatGPT更不可靠,特别是如果你想要你的DBA。In fact, people ask questions to ChatGPT and vote or next to the answer to help the AI learn. In other words, we are looking at an alpha version, and we are helping it become better.
有趣的话题(GPT的东西)。我不知道会发生什么在10年左右。
我将试着把这篇博客的文本ChatGPT然后再问同样的问题。