Mysql on SRE运维博客

使用AWS Lambda自动化导出RDS数据库快照的详细指南

Wenlong — Sat, 14 Sep 2024 10:24:25 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/240914102425/
相关话题：https://www.cnsre.cn/tags/lambda/

使用AWS Lambda自动化导出RDS数据库快照的详细指南

引言：为什么选择Lambda来导出数据库快照？

在现代云计算环境中，自动化任务是提升效率和降低人为错误的关键。AWS Lambda 是一种无服务器计算服务，允许我们运行代码而无需管理服务器基础设施。在数据库管理中，自动化导出RDS（Relational Database Service）数据库快照是一个常见需求，而Lambda 可以帮助我们高效、灵活地完成这一任务。

背景：使用Lambda自动化RDS快照导出的优势

AWS RDS提供了强大的数据库管理功能，包括备份和恢复。定期导出RDS快照到S3桶中，可以实现数据的长期存档和分析。通过AWS Lambda，我们可以将这一过程自动化，从而减少手动操作并降低出错风险。

Lambda函数实现：自动化导出RDS快照

以下是一个完整的AWS Lambda函数示例，展示如何自动化导出RDS数据库快照。这个脚本使用Python编写，并结合了AWS SDK for Python（Boto3）来与AWS服务进行交互。

Lambda函数示例代码

import boto3
import datetime

def lambda_handler(event, context):
    # 获取当前日期的前一天
    previous_date = datetime.datetime.now() - datetime.timedelta(days=1)
    previous_date_str = previous_date.strftime("%Y-%m-%d")
    # 获取当前日期
    current_date = datetime.datetime.now().strftime("%Y-%m-%d")

    # 构建导出任务的参数
    export_task_identifier = f"export-db-snapshot-{previous_date_str}"
    source_arn = f"arn:aws:rds:region:account-id:snapshot:rds:db-instance-{previous_date_str}-snapshot"
    s3_bucket_name = "your-s3-bucket-name"
    s3_prefix = f"rds-export/{current_date}"
    iam_role_arn = "arn:aws:iam::account-id:role/your-lambda-role"
    export_only = ["your_table_name"]
    kms_key_id = "your-kms-key-id"

    # 创建RDS客户端
    rds_client = boto3.client("rds")

    # 启动导出任务
    response = rds_client.start_export_task(
        ExportTaskIdentifier=export_task_identifier,
        SourceArn=source_arn,
        S3BucketName=s3_bucket_name,
        S3Prefix=s3_prefix,
        IamRoleArn=iam_role_arn,
        ExportOnly=export_only,
        KmsKeyId=kms_key_id
    )

    # 输出任务启动结果
    print(response)

代码详细解析

1. 获取日期和时间

1
2
3

previous_date = datetime.datetime.now() - datetime.timedelta(days=1)
previous_date_str = previous_date.strftime("%Y-%m-%d")
current_date = datetime.datetime.now().strftime("%Y-%m-%d")

我们计算前一天的日期用于指定要导出的快照，并使用当前日期生成S3桶中的路径。这种方法能够确保快照文件被有序存储。

2. 构建导出任务参数

export_task_identifier = f"export-db-snapshot-{previous_date_str}"
source_arn = f"arn:aws:rds:region:account-id:snapshot:rds:db-instance-{previous_date_str}-snapshot"
s3_bucket_name = "your-s3-bucket-name"
s3_prefix = f"rds-export/{current_date}"
iam_role_arn = "arn:aws:iam::account-id:role/your-lambda-role"
export_only = ["your_table_name"]
kms_key_id = "your-kms-key-id"

在这里，我们设置了导出任务的标识符、源快照ARN、目标S3桶及路径、IAM角色、导出的数据表以及KMS密钥。每个参数的配置都对任务的执行至关重要。

3. 启动导出任务

response = rds_client.start_export_task(
    ExportTaskIdentifier=export_task_identifier,
    SourceArn=source_arn,
    S3BucketName=s3_bucket_name,
    S3Prefix=s3_prefix,
    IamRoleArn=iam_role_arn,
    ExportOnly=export_only,
    KmsKeyId=kms_key_id
)
print("Export Task Started Successfully:", response)

通过调用start_export_task方法，我们启动了导出任务，并将参数传递给AWS RDS。成功启动任务后，我们可以查看响应确认任务已正确执行。

4. 错误处理

1
2
3

except Exception as e:
    print("Error starting export task:", e)
    raise e

错误处理部分确保了在启动导出任务时如果发生异常，能够记录错误信息并抛出异常，方便后续排查。

总结：Lambda与RDS快照导出的无缝集成

通过AWS Lambda自动化导出RDS数据库快照，我们能够显著提升数据管理的效率。这种自动化不仅简化了操作流程，还减少了人为错误的风险，使得数据备份和存档变得更加可靠。

希望这个文章能帮助您实现数据库快照的自动化导出。

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/240914102425/
相关话题：https://www.cnsre.cn/tags/lambda/

深入探索 Aurora MySQL 配置及使用掌握关键参数与高可用性架构

Wenlong — Fri, 13 Sep 2024 10:24:10 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/240913102410/
相关话题：https://www.cnsre.cn/tags/aws/

Amazon Aurora 是 AWS 提供的一种高性能、高可用性的数据库解决方案，特别是在大型应用程序中表现尤为出色。今天，我们将通过实际实验深入了解 Aurora MySQL 的核心架构、容错能力，以及如何根据需求灵活配置参数。相信通过此次探讨，您将获得更多关于 Aurora 数据库的启示，并能自如应对实际工作中的挑战。

1. Aurora MySQL 的架构与工作原理

首先，Amazon Aurora MySQL 的架构相当独特。它由一个集群卷和多个数据库实例组成，集群卷跨越多个 AWS 可用区，这为数据的持久性和安全性提供了坚实的基础。Aurora 分为两类数据库实例：

主数据库实例：支持读写操作，是数据修改的主要入口。
Aurora 副本：仅支持读取操作，通过从主数据库实例分担读取负载来提高集群的性能。

我们通过实验发现，当主数据库实例出现问题时，Aurora 会自动将其副本提升为新的主实例，确保数据库的高可用性。这一过程几乎不需要手动干预，极大地提高了服务的稳定性。

实验：主实例自动故障转移

在实验中，我们模拟了主实例的故障。通过故意终止主实例，Aurora 迅速提升了一个副本为新的主实例，整个过程在不到 60 秒的时间内完成。这不仅展现了 Aurora 的快速响应能力，还验证了其在高可用性场景中的可靠性。

2. 了解 Aurora MySQL 的关键配置参数

在 Aurora MySQL 的配置过程中，某些关键参数会直接影响集群的性能与可用性。我们在实验中探索了这些参数的作用：

DB 引擎版本：Aurora 支持多个 MySQL 版本，目前最新的版本为 2.11.0（在部分地区已发布）。不同版本间可能存在兼容性差异，因此在选择时需特别注意。
复制设置：Aurora 允许最多 15 个副本，这些副本不仅提升了读取性能，还能在主实例故障时发挥关键作用。

实验：集群扩展与性能测试

为了验证 Aurora 在扩展方面的能力，我们向现有的集群中添加了多个副本，并测试了在高并发读取场景下的响应时间。结果表明，随着副本数量的增加，集群的读取吞吐量大幅提升，同时响应延迟显著降低。

这意味着，对于需要高并发读操作的应用程序而言，适当增加 Aurora 副本数量可以有效提升性能。

3. 容错能力与数据安全

Aurora 的容错设计体现在它的集群卷跨越多个可用区。当其中一个可用区出现故障时，其他可用区的数据副本能够立即接管，确保服务不中断。

实验：可用区故障模拟

我们模拟了某个可用区的故障，观察 Aurora 如何应对。实验中，Aurora 集群在不丢失任何数据的情况下，快速从其他可用区恢复服务。数据库的短暂中断时间约为几秒钟，几乎对应用程序没有明显影响。

这一实验再次证明了 Aurora 在数据安全和高可用性方面的卓越设计。

4. Aurora 终端节点类型

Aurora 数据库集群提供了多种终端节点，用于支持不同的操作需求：

集群终端节点：用于主实例的读写操作。
读取器终端节点：将读请求分配给多个副本，平衡读取负载。
实例终端节点：针对特定的数据库实例进行操作。

在日常操作中，正确使用这些终端节点能够显著提升数据库性能与管理的便利性。我们通过实验发现，使用读取器终端节点可以有效分散读取压力，特别是在大规模并发读取的场景下。

实验：终端节点的选择与负载分配

通过实验，我们向 Aurora 集群发出了大量并发请求，并通过读取器终端节点分配这些请求给不同的副本，结果读取延迟得到了极大的降低。这表明，通过合理利用不同类型的终端节点，我们能够有效提高数据库的响应速度。

结论

通过本次实验，我们深入理解了 Amazon Aurora MySQL 的关键架构和配置参数，并验证了其在高可用性、性能优化以及容错设计方面的卓越表现。Aurora 的自动故障转移机制、高效的副本管理和灵活的终端节点配置，使其成为企业级应用中极具吸引力的数据库解决方案。

在未来的工作中，您可以根据业务需求，灵活调整 Aurora 的配置，以充分发挥其潜力。如果您有更复杂的场景或特殊需求，建议深入研究 Aurora 文档，并结合实际环境进行更多实验。

参考资料

[1] Amazon Aurora 数据库集群
[2] Amazon Aurora MySQL 2 的数据库引擎更新
[3] Aurora 数据库集群的容错能力
[4] Aurora 终端节点的类型

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/240913102410/
相关话题：https://www.cnsre.cn/tags/aws/

数据库CPU 100%问题分析与解决方案 - 提升性能

Wenlong — Tue, 13 Apr 2021 13:10:21 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210413131020/
相关话题：https://www.cnsre.cn/tags/故障集/

问题描述

2020年7月13日一大早收到告警，测试环境数据库CPU告警。

登录aws查看监控如下图

问题分析

出现这种cpu 100%的问题，一般都是因为sql性能问题导致的。
主要表现于 cpu消耗过大，有慢sql造成、慢sql全表扫描，扫描数据库过大，内存排序，队列等等
并发现写入相对于查询来说比较高（这是一个关键点）
有了大概的思路下边开始排查吧

查看进程

show full processlist;

发现有大量的语句状态为 sending data sending data: sql正从表中查询数据，如果查询条件没有适当索引，会导致sql执行时间过长。

查看慢日志配置

mysql> show variables like 'slow_query%';
+---------------------+----------------------------------------------+
| Variable_name       | Value                                        |
+---------------------+----------------------------------------------+
| slow_query_log      | ON                                           |
| slow_query_log_file | /rdsdbdata/log/slowquery/mysql-slowquery.log |
+---------------------+----------------------------------------------+
2 rows in set
mysql> show variables like 'slow_launch_time';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| slow_launch_time | 1     |
+------------------+-------+
1 row in set

看到慢日志已经开启

登录aws cloudwatch查看慢日志发现大部分为这条sql

# User@Host: admin[admin] @  [10.0.11.12]  Id:  2302
# Query_time: 3.602910  Lock_time: 0.100585 Rows_sent: 2  Rows_examined: 4454
SET timestamp=1594629311;
SELECT a.enum_value,a.enum_value
        FROM external_mapping a
        LEFT JOIN external_command_key b ON a.command_id=b.id
        LEFT JOIN external_command_options c ON a.options_id=c.id
        LEFT JOIN external_command_key d ON a.command_id=d.id
        LEFT JOIN category h ON a.category_id=h.id
        where 1=1
            AND b.code='Common.Status.Event'
            AND c.code='Common.Setting.Rm4Valve'
            AND d.code='Rm4_Valve'
            AND a.platform_id=119
            AND h.cname = 'TT';

查看是否有锁表

mysql> show OPEN TABLES where In_use > 0;
#查看是否有锁表
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
#查看正在锁的事务
Empty set
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 
#查看等待锁的事务
Empty set
暂时没有看到锁表的情况

查看缓存命中

mysql> show global status like 'Qca%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| Qcache_free_blocks      | 1         |
| Qcache_free_memory      | 134199912 |
| Qcache_hits             | 0         |
| Qcache_inserts          | 0         |
| Qcache_lowmem_prunes    | 0         |
| Qcache_not_cached       | 44950579  |
| Qcache_queries_in_cache | 0         |
| Qcache_total_blocks     | 1         |
+-------------------------+-----------+

Qcache_hits：查询缓存命中次数。
Qcache_inserts：将查询和结果集写入到查询缓存中的次数。
Qcache_not_cached：不可以缓存的查询次数。
Qcache_queries_in_cache：查询缓存中缓存的查询量。

查看到缓存命中为0%

查看引擎状态

mysql> show engine innodb status;

通过上边一系列的查询，发现以下几个问题

1、慢查询、全表扫描过多

描述

慢sql：查看到sql语句执行时间过长。

全表扫描：这个策略用于检查百分比（(Handler_read_rnd+Handler_read_rnd_next)/(Handler_read_first+Handler_read_key+Handler_read_next+Handler_read_prev+Handler_read_rnd+Handler_read_rnd_next)）。这是一个需要读取全表内容的操作，而不是仅读取使用索引选定的部分。通常使用小型查找表执行，或者在具有大型表的数据仓库情况下执行而其中所有可用数据都被聚合和分析。

建议

慢sql： 根据sql 检查语句并进行索引优化。

全表扫描:应该尽量保持这个值尽可能的低。尝试隔离那些不使用索引的查询。一旦识别了那些查询，请创建适当的索引或重写查询以使用索引。MySQL 有一个很棒的功能 - 慢速查询日志，它允许你记录所有需要超过指定时间运行的查询。慢速速查询日志可用于识别需要很长时间才能完成的查询。

2、数据库最大并发连接数量

描述
当服务器启动后，（max_used_connections）变量将提供一个基准，以帮助你确定服务器支持的最大连接数量。它还可以帮助进行流量分析。
建议
如果需要支持更多的连接，应该增加变量 max_connections 的值。MySQL 支持的最大连接数量是取决于给定平台上线程库的质量、可用 RAM 的数量、每个连接可使用多少 RAM、每个连接的工作负载以及所需的响应时间。

3、查询缓存要配置

缓存描述
这个策略用于检查查询缓存命中率（Qcache_hits/(Qcache_hits + Com_select)）。 MySQL 查询缓存将缓存一个分析的查询及其整个结果集。当你有许多小型的查询返回小型数据集时，这是非常好的，因为查询缓存将允许返回结果立即可供使用，而不是每次发生时都重新运行查询。
建议
理想情况下，查询缓存的命中率应该接近 100%。MySQL 的查询缓存是一项强大的技术，并且在管理良好的情况下可以显着提高数据库的吞吐量。一旦你的应用程序被创建，你可以看看它如何使用数据库，并相应地调整查询缓存。有足够大的缓存，避免碎片化和排除大型的查询，你就应该能够保持极高的缓存命中率，并享受出色的性能。

处理过程

根据上边发现的问题进行了配置的修改

1、修改慢查询以及全表扫描

此问题联系开发进行索引优化，减少全表扫描。

2、数据库最大连接数量

修改配置 max_user_connections 我这边设置的为1000

3、查询缓存的配置

query_cache_size：分配用于缓存查询结果的内存量。
query_cache_limit：不要缓存大于此字节数的结果。
query_cache_type：对于查询结果，不缓存（= OFF），不缓存NO_CACHE（= ON），或仅缓存（= DEMAND）分别用012 表示

修改完数据但是需要重启才能生效。

问题解决

正在准备空闲时间重启RDS的时候，开发那边有了进展。
开发同事把缓存写错了！！！！😳😳😳

总结

理下业务
程序暴露接口给测试部门，测试部门在上报了50W条数据，开发这边程序有没有添加数据过滤（过滤掉垃圾数据），并且…开发在程序中写错了缓存。所以导致相对于读取来说写入较高。因为在缓存查询不到想到的数据，就进行了全表扫描，继而出现了大量进程以及连接数队列等等。。
处理问题可以，别主动背锅。。。在接手数据库的时候最好检查下配置，了解数据库的情况，在出现问题的时候能够最快速的定位解决问题。
另外，经过此次的故障处理，加固了对业务以及数据库一些参数的理解。

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210413131020/
相关话题：https://www.cnsre.cn/tags/故障集/

数据库备份脚本：在Linux上自动化MySQL备份

Wenlong — Wed, 24 Mar 2021 14:48:35 +0800

数据库备份脚本

#!/bin/bash
# 以下配置信息请自己修改
mysql_user="backuser" # MySQL备份用户
mysql_password="" # MySQL备份用户的密码
mysql_host=""
mysql_port="3306"
mysql_charset="utf8" # MySQL编码
backup_db_arr=("da1") # 要备份的数据库名称，多个用空格分开隔开 如("db1" "db2" "db3")
backup_location=/home/backup/sqlback/recipe-prod # 备份数据存放位置，末尾请不要带"/",此项可以保持默认，程序会自动创建文件夹
expire_backup_delete="ON" # 是否开启过期备份删除 ON为开启 OFF为关闭
expire_days=3 # 过期时间天数 默认为三天，此项只有在expire_backup_delete开启时有效

# 本行开始以下不需要修改
backup_time=`date +%Y%m%d%H%M` # 定义备份详细时间
backup_Ymd=`date +%Y-%m-%d` # 定义备份目录中的年月日时间
backup_3ago=`date -d '3 days ago' +%Y-%m-%d` # 3天之前的日期
backup_dir=$backup_location/$backup_Ymd # 备份文件夹全路径
welcome_msg="欢迎使用数据库备份工具!" # 欢迎语

echo -e "\033[1;32m$welcome_msg \033[0m"
# 连接到mysql数据库，无法连接则备份退出
mysql -h$mysql_host -P$mysql_port -u$mysql_user -p$mysql_password <<end
use mysql;
select host,user from user where user='root' and host='localhost';
exit
end

flag=`echo $?`
if [ $flag != "0" ]; then
echo -e "\033[1;31m错误：无法连接mysql服务器！停止备份！\033[0m"
exit
else
echo -e "\033[1;32mMySQL连接成功！请稍候...... \033[0m"

# 判断有没有定义备份的数据库，如果定义则开始备份，否则退出备份
if [ "$backup_db_arr" != "" ];then
for dbname in ${backup_db_arr[@]}
do
echo -e "\033[1;32m数据库 $dbname 开始备份...\033[0m"
`mkdir -p $backup_dir`
`mysqldump -h$mysql_host -P$mysql_port -u$mysql_user -p$mysql_password $dbname --default-character-set=$mysql_charset | gzip > $backup_dir/$dbname-$backup_time.sql.gz`
flag=`echo $?`
if [ $flag == "0" ];then
echo -e "\033[1;32m数据库 $dbname 成功备份到 $backup_dir/$dbname-$backup_time.sql.gz \033[0m"
else
echo -e "\033[1;31m数据库 $dbname 备份失败！\033[0m"
fi
done
else
echo -e  "\033[1;31m错误：没有要备份的数据库！停止备份！\033[0m"
exit
fi

# 如果开启了删除过期备份，则进行删除操作
if [ "$expire_backup_delete" == "ON" -a "$backup_location" != "" ];then
`find $backup_location/ -type d -mtime +$expire_days | xargs rm -rf`
echo -e "\033[1;32m过期的备份数据删除完成！ \033[0m"
fi
echo -e "\033[1;32m所有数据库备份成功！谢谢！ \033[0m"
exit
fi

文章链接

Mysql on SRE运维博客

使用AWS Lambda自动化导出RDS数据库快照的详细指南

使用AWS Lambda自动化导出RDS数据库快照的详细指南

引言：为什么选择Lambda来导出数据库快照？

背景：使用Lambda自动化RDS快照导出的优势

Lambda函数实现：自动化导出RDS快照

Lambda函数示例代码

代码详细解析

1. 获取日期和时间

2. 构建导出任务参数

3. 启动导出任务

4. 错误处理

总结：Lambda与RDS快照导出的无缝集成

深入探索 Aurora MySQL 配置及使用 掌握关键参数与高可用性架构

1. Aurora MySQL 的架构与工作原理

实验：主实例自动故障转移

2. 了解 Aurora MySQL 的关键配置参数

实验：集群扩展与性能测试

3. 容错能力与数据安全

实验：可用区故障模拟

4. Aurora 终端节点类型

实验：终端节点的选择与负载分配

结论

参考资料

数据库CPU 100%问题分析与解决方案 - 提升性能

问题描述

登录aws查看监控如下图

问题分析

查看进程

查看慢日志配置

查看是否有锁表

查看缓存命中

查看引擎状态

1、慢查询、全表扫描过多

2、数据库最大并发连接数量

3、查询缓存要配置

处理过程

1、修改慢查询以及全表扫描

2、数据库最大连接数量

3、查询缓存的配置

问题解决

总结

数据库备份脚本：在Linux上自动化MySQL备份

数据库备份脚本

深入探索 Aurora MySQL 配置及使用掌握关键参数与高可用性架构