作者： HaHaNone

1. nginx安装stream库: apt install libnginx-mod-stream
2. 修改/etc/nginx.conf

stream {
server {
listen 8443;
proxy_connect_timeout 5s;
proxy_timeout 10s;
proxy_pass 146.235.19.162:8443; # 转发
}
server {
listen 8443 udp reuseport;
proxy_timeout 10s;
proxy_pass 146.235.19.162:8443;
}
}

(1)master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；
(2)slave将master的binary log events拷贝到它的中继日志(relay log)；
(3)slave重做中继日志中的事件，将改变反映它自己的数据；

主库：
1. vim /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
server-id=1
log-bin=/var/log/mysql/mysql-bin.log
2.
create user ‘apollo’@’%’ identified by ‘apollo123’;
grant replication slave on . to ‘apollo’@’%’;
flush table with read lock;
show master status; // 记录下File、Position后面从库会用到，例如a-mysql-bin.000001，615
3.
mysqldump -uroot -p –all-databases > /root/root.sql

从库：
1. vim /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
server-id=2
2.scp root@192.168.13.183:/root/root.sql /root/root.sql
登录mysql：
source /opt/root.sql
3. 添加master配置：
change master to master_host=’192.168.13.189′,
master_user=’apollo’,
master_password=’apollo123′,
master_log_file=’a-mysql-bin.000001′,
master_log_pos=615;
4.
start slave;
检查同步状态：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

收尾：
主库执行：unlock tables;

一个WoedPress站点至少包含如下三个主要元素：

• WordPress本身
• wp-content目录的内容，包括：主题（themes)、插件（plugins)和上传目录（uploads）
• 数据库，所有的内容都会保存在这里

WordPress使用一些数据库表来存储它们之间的关系——采用一对多的关系。这意味着，一个用户可以有很多文章，而且都会关联到他们的记录中。这样可以节省空间——如果WordPress为每个用户都保存一份数据而不是每篇文章，就会需要很多数据而且占用很多空间。

大多数表都是通过一个子段来关联到其他的一个或者多个表。这些子段都是每一条记录的唯一标示，例如：post_id;

TABLE	DATA STORED	LINKED TO
wp_posts	文章，页面，附件，版本和菜单导航项	wp_postmeta (via post_id) wp_term_relationships(viapost_id)
wp_postmeta	每篇文章的元数据	wp_posts (via post_id)
wp_comments	评论	wp_posts (via post_id)
wp_commentmeta	评论的元数据	wp_comments (via comment_id)
wp_term_relationships	文章和分类法的关系	wp_posts (via post_id) wp_term_taxonomy (viaterm_taxonomy_id)
wp_term_taxonomy	分类法（包括分类和标签）	wp_term_relationships (viaterm_taxonomy_id)
wp_terms	你的分类、标签和分配到自定义分类法的分类项目	wp_term_taxonomy (via term_id)
wp_links	博客中的链接	wp_term_relationships (vialink_id)
wp_users	用户	wp_posts (via post_author)
wp_user_meta	每个用户的元数据	wp_users (via user_id)
wp_options	站点的设置选项（通过设置界面、主题和插件添加的）

还有一些需要注意的事情：

• wp_posts 是核心表，你的大多数数据都在这里保存。它几乎把所有的内容的组织在一起。
• 只有一个表是和其他表没有关系的—— wp_options。这个表保存着站点和 WordPress 安装信息，这些内容没有和文章或者用户有关联。
• wp_users 和wp_comments表是没有关联的——尽管用户可能会需要注册才能发表评，WordPress 没有真正地保存关于每个用户的评论以及谁发布的。
• 一个多站点安装将会有一些扩展表。这里没有包含这些内容，因为已经超出了这个系列的内容。

内容和数据库表的关系:

CONTENT TYPE	TABLE(S)
文章	wp_posts
页面	wp_posts
自定义文章类型	wp_posts
附件	wp_posts
链接	wp_links
导航菜单项目	wp_posts
分类	wp_terms
标签	wp_terms
自定义分类法	wp_term_taxonomy
分类法项目	wp_terms
文章元数据	wp_post_meta
小工具	wp_options
选项	wp_options
用户	wp_users
硬编码内容	wp_posts （如果添加到文章中） wp_options （如果添加到小工具中） 主题和插件文件（如果是硬编码）
第三方内容	wp_posts （如果添加到文章中） wp_options （如果是小工具或插件添加的） 主题和插件文件（如果是硬编码）

环境依赖

第一步：perf record 记录采集的性能数据

perf record -e cpu-clock -g -p $(pgrep test_lvgl)

• -e cpu-clock：使用 cpu-clock 事件，该事件测量在被分析的进程中花费的 CPU 时间
• -g：记录调用图（即堆栈跟踪）
• -p：指定要分析的进程ID

程序运行完之后，perf record会生成一个名为perf.data的文件，如果之前已有，那么之前的perf.data文件会被覆盖。
可以执行perf report -i perf.data，（-i 指定要查看的文件），来查看报告，但非常不直观，所以需要火焰图。

第二步：perf script 解析perf.data数据

perf script -i perf.data &> perf.unfold

将perf.unfold 拷贝到本地机器，再本地生成火焰图。

第三步：使用FlameGraph生成火焰图

https://github.com/brendangregg/FlameGraph

./stackcollapse-perf.pl perf.unfold &> perf.folded
./flamegraph.pl perf.folded > perf.svg

执行 stackcollapse-perf.pl 将 perf.unfold 中的符号进行折叠。
执行 flamegraph.pl 生成 火焰图。

第四步：火焰图分析

火焰图查看说明：

• y轴代表调用栈，每一层都是一个函数调用，栈越深则火焰越高，调用关系是从下而上的，即下层函数调用了上层函数。
• x轴代表抽样数，一个函数在x轴占据的宽度越宽，则表示它被抽样到的次数也就越多，也就是说它执行的时间越长。

火焰图就是看函数占据的宽度，宽度越大可能存在性能问题。
颜色没有特殊含义，因为火焰图表示的是 CPU 的繁忙程度，所以一般选择暖色调。
鼠标放到一个函数上后，会展示完整的函数名，被抽样中的次数，占总抽样次数的百分比

问题

• svg图出现unknown函数

perf record -e cpu-clock –call-graph dwarf -p pid

dwarf 是一种调试信息格式，它可以提供非常详细的函数调用信息。

增加—call-graph dwarf 参数后record生成的perf.data会变大，这里要注意设备空间。