binlog 基本认识 MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。 一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版)。二进制有两个最重要的使用场景: 其一：MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。 其二：自然就是数据恢复了，通过使用mysqlbinlog工具来使恢复数据。 二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件。 一、开启binlog日志： vi编辑打开mysql配置文件 # vi /usr/local/mysql/etc/my.cnf 在[mysqld] 区块 设置/添加 log-bin=mysql-bin 确认是打开状态(值 mysql-bin 是日志的基本名或前缀名)； 重启mysqld服务使配置生效 # pkill mysqld # /usr/local/mysql/bin/mysqld_safe --user=mysql & 二、也可登录mysql服务器，通过mysql的变量配置表，查看二进制日志是否已开启 单词：variable[ˈvɛriəbəl] 变量 登录服务器 # /usr/local/mysql/bin/mysql -uroot -p123456 mysql> show variables like 'log_%'; +----------------------------------------+---------------------------------------+ | Variable_name | Value | +----------------------------------------+---------------------------------------+ | log_bin | ON | ------> ON表示已经开启binlog日志 | log_bin_basename | /usr/local/mysql/data/mysql-bin | | log_bin_index | /usr/local/mysql/data/mysql-bin.index | | log_bin_trust_function_creators | OFF | | log_bin_use_v1_row_events | OFF | | log_error | /usr/local/mysql/data/martin.err | | log_output | FILE | | log_queries_not_using_indexes | OFF | | log_slave_updates | OFF | | log_slow_admin_statements | OFF | | log_slow_slave_statements | OFF | | log_throttle_queries_not_using_indexes | 0 | | log_warnings | 1 | +----------------------------------------+---------------------------------------+ 三、常用binlog日志操作命令 1.查看所有binlog日志列表 mysql> show master logs; 2.查看master状态，即最后(最新)一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值 mysql> show master status; 3.刷新log日志，自此刻开始产生一个新编号的binlog日志文件 mysql> flush logs; 注：每当mysqld服务重启时，会自动执行此命令，刷新binlog日志；在mysqldump备份数据时加 -F 选项也会刷新binlog日志； 4.重置(清空)所有binlog日志 mysql> reset master; 四、查看某个binlog日志内容，常用有两种方式： 1.使用mysqlbinlog自带查看命令法： 注: binlog是二进制文件，普通文件查看器cat more vi等都无法打开，必须使用自带的 mysqlbinlog 命令查看 binlog日志与数据库文件在同目录中(我的环境配置安装是选择在/usr/local/mysql/data中) 在MySQL5.5以下版本使用mysqlbinlog命令时如果报错，就加上 “--no-defaults”选项 # /usr/local/mysql/bin/mysqlbinlog /usr/local/mysql/data/mysql-bin.000013 下面截取一个片段分析： ............................................................................... # at 552 #131128 17:50:46 server id 1 end_log_pos 665 Query thread_id=11 exec_time=0 error_code=0 ---->执行时间:17:50:46；pos点:665 SET TIMESTAMP=1385632246/*!*/; update zyyshop.stu set name='李四' where id=4 ---->执行的SQL /*!*/; # at 665 #131128 17:50:46 server id 1 end_log_pos 692 Xid = 1454 ---->执行时间:17:50:46；pos点:692 ............................................................................... 注: server id 1 数据库主机的服务号； end_log_pos 665 pos点 thread_id=11 线程号 2.上面这种办法读取出binlog日志的全文内容较多，不容易分辨查看pos点信息，这里介绍一种更为方便的查询命令： mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]; 选项解析： IN 'log_name' 指定要查询的binlog文件名(不指定就是第一个binlog文件) FROM pos 指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算) LIMIT [offset,] 偏移量(不指定就是0) row_count 查询总条数(不指定就是所有行) 截取部分查询结果： *************************** 20. row *************************** Log_name: mysql-bin.000021 ----------------------------------------------> 查询的binlog日志文件名 Pos: 11197 ----------------------------------------------------------> pos起始点: Event_type: Query ----------------------------------------------------------> 事件类型：Query Server_id: 1 --------------------------------------------------------------> 标识是由哪台服务器执行的 End_log_pos: 11308 ----------------------------------------------------------> pos结束点:11308(即：下行的pos起始点) Info: use `zyyshop`; INSERT INTO `team2` VALUES (0,345,'asdf8er5') ---> 执行的sql语句 *************************** 21. row *************************** Log_name: mysql-bin.000021 Pos: 11308 ----------------------------------------------------------> pos起始点:11308(即：上行的pos结束点) Event_type: Query Server_id: 1 End_log_pos: 11417 Info: use `zyyshop`; /*!40000 ALTER TABLE `team2` ENABLE KEYS */ *************************** 22. row *************************** Log_name: mysql-bin.000021 Pos: 11417 Event_type: Query Server_id: 1 End_log_pos: 11510 Info: use `zyyshop`; DROP TABLE IF EXISTS `type` 这条语句可以将指定的binlog日志文件，分成有效事件行的方式返回，并可使用limit指定pos点的起始偏移，查询条数； A.查询第一个(最早)的binlog日志： mysql> show binlog events\G; B.指定查询 mysql-bin.000021 这个文件： mysql> show binlog events in 'mysql-bin.000021'\G; C.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起： mysql> show binlog events in 'mysql-bin.000021' from 8224\G; D.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，查询10条 mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 10\G; E.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，偏移2行，查询10条 mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 2,10\G; 五、恢复binlog日志实验(zyyshop是数据库) 1.假设现在是凌晨4:00，我的计划任务开始执行一次完整的数据库备份： 将zyyshop数据库备份到 /root/BAK.zyyshop.sql 文件中： # /usr/local/mysql/bin/mysqldump -uroot -p123456 -lF --log-error=/root/myDump.err -B zyyshop > /root/BAK.zyyshop.sql ...... 大约过了若干分钟，备份完成了，我不用担心数据丢失了，因为我有备份了，嘎嘎~~~ 由于我使用了-F选项，当备份工作刚开始时系统会刷新log日志，产生新的binlog日志来记录备份之后的数据库“增删改”操作，查看一下： mysql> show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000023 | 120 | | | +------------------+----------+--------------+------------------+ 也就是说， mysql-bin.000023 是用来记录4:00之后对数据库的所有“增删改”操作。 2.早9:00上班了，业务的需求会对数据库进行各种“增删改”操作~~~~~~~ @ 比如：创建一个学生表并插入、修改了数据等等： CREATE TABLE IF NOT EXISTS `tt` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(16) NOT NULL, `sex` enum('m','w') NOT NULL DEFAULT 'm', `age` tinyint(3) unsigned NOT NULL, `classid` char(6) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 导入实验数据 mysql> insert into zyyshop.tt(`name`,`sex`,`age`,`classid`) values('yiyi','w',20,'cls1'),('xiaoer','m',22,'cls3'),('zhangsan','w',21,'cls5'),('lisi','m',20,'cls4'),('wangwu','w',26,'cls6'); 查看数据 mysql> select * from zyyshop.tt; +----+----------+-----+-----+---------+ | id | name | sex | age | classid | +----+----------+-----+-----+---------+ | 1 | yiyi | w | 20 | cls1 | | 2 | xiaoer | m | 22 | cls3 | | 3 | zhangsan | w | 21 | cls5 | | 4 | lisi | m | 20 | cls4 | | 5 | wangwu | w | 26 | cls6 | +----+----------+-----+-----+---------+ 中午时分又执行了修改数据操作 mysql> update zyyshop.tt set name='李四' where id=4; mysql> update zyyshop.tt set name='小二' where id=2; 修改后的结果： mysql> select * from zyyshop.tt; +----+----------+-----+-----+---------+ | id | name | sex | age | classid | +----+----------+-----+-----+---------+ | 1 | yiyi | w | 20 | cls1 | | 2 | 小二 | m | 22 | cls3 | | 3 | zhangsan | w | 21 | cls5 | | 4 | 李四 | m | 20 | cls4 | | 5 | wangwu | w | 26 | cls6 | +----+----------+-----+-----+---------+ 假设此时是下午18:00，莫名地执行了一条悲催的SQL语句，整个数据库都没了： mysql> drop database zyyshop; 3.此刻杯具了，别慌！先仔细查看最后一个binlog日志，并记录下关键的pos点，到底是哪个pos点的操作导致了数据库的破坏(通常在最后几步)； 备份一下最后一个binlog日志文件： # ll /usr/local/mysql/data | grep mysql-bin # cp -v /usr/local/mysql/data/mysql-bin.000023 /root/ 此时执行一次刷新日志索引操作，重新开始新的binlog日志记录文件，理论说 mysql-bin.000023 这个文件不会再有后续写入了(便于我们分析原因及查找pos点)，以后所有数据库操作都会写入到下一个日志文件； mysql> flush logs; mysql> show master status; 4.读取binlog日志，分析问题 方式一：使用mysqlbinlog读取binlog日志： # /usr/local/mysql/bin/mysqlbinlog /usr/local/mysql/data/mysql-bin.000023 方式二：登录服务器，并查看(推荐)： mysql> show binlog events in 'mysql-bin.000023'; 以下为末尾片段： +------------------+------+------------+-----------+-------------+------------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+------+------------+-----------+-------------+------------------------------------------------------------+ | mysql-bin.000023 | 922 | Xid | 1 | 953 | COMMIT /* xid=3820 */ | | mysql-bin.000023 | 953 | Query | 1 | 1038 | BEGIN | | mysql-bin.000023 | 1038 | Query | 1 | 1164 | use `zyyshop`; update zyyshop.tt set name='李四' where id=4| | mysql-bin.000023 | 1164 | Xid | 1 | 1195 | COMMIT /* xid=3822 */ | | mysql-bin.000023 | 1195 | Query | 1 | 1280 | BEGIN | | mysql-bin.000023 | 1280 | Query | 1 | 1406 | use `zyyshop`; update zyyshop.tt set name='小二' where id=2| | mysql-bin.000023 | 1406 | Xid | 1 | 1437 | COMMIT /* xid=3823 */ | | mysql-bin.000023 | 1437 | Query | 1 | 1538 | drop database zyyshop | +------------------+------+------------+-----------+-------------+------------------------------------------------------------+ 通过分析，造成数据库破坏的pos点区间是介于 1437--1538 之间，只要恢复到1437前就可。 5.现在把凌晨备份的数据恢复： # /usr/local/mysql/bin/mysql -uroot -p123456 -v < /root/BAK.zyyshop.sql; 注: 至此截至当日凌晨(4:00)前的备份数据都恢复了。 但今天一整天(4:00--18:00)的数据肿么办呢？就得从前文提到的 mysql-bin.000023 新日志做文章了...... 6.从binlog日志恢复数据 恢复语法格式： # mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名 常用选项： --start-position=953 起始pos点 --stop-position=1437 结束pos点 --start-datetime="2013-11-29 13:18:54" 起始时间点 --stop-datetime="2013-11-29 13:21:53" 结束时间点 --database=zyyshop 指定只恢复zyyshop数据库(一台主机上往往有多个数据库，只限本地log日志) 不常用选项： -u --user=name Connect to the remote server as username.连接到远程主机的用户名 -p --password[=name] Password to connect to remote server.连接到远程主机的密码 -h --host=name Get the binlog from server.从远程主机上获取binlog日志 --read-from-remote-server Read binary logs from a MySQL server.从某个MySQL服务器上读取binlog日志 小结：实际是将读出的binlog日志内容，通过管道符传递给mysql命令。这些命令、文件尽量写成绝对路径； A.完全恢复(本例不靠谱，因为最后那条 drop database zyyshop 也在日志里，必须想办法把这条破坏语句排除掉，做部分恢复) # /usr/local/mysql/bin/mysqlbinlog /usr/local/mysql/data/mysql-bin.000021 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop B.指定pos结束点恢复(部分恢复)： @ --stop-position=953 pos结束点 注：此pos结束点介于“导入实验数据”与更新“name='李四'”之间，这样可以恢复到更改“name='李四'”之前的“导入测试数据” # /usr/local/mysql/bin/mysqlbinlog --stop-position=953 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop 在另一终端登录查看结果(成功恢复了)： mysql> select * from zyyshop.tt; +----+----------+-----+-----+---------+ | id | name | sex | age | classid | +----+----------+-----+-----+---------+ | 1 | yiyi | w | 20 | cls1 | | 2 | xiaoer | m | 22 | cls3 | | 3 | zhangsan | w | 21 | cls5 | | 4 | lisi | m | 20 | cls4 | | 5 | wangwu | w | 26 | cls6 | +----+----------+-----+-----+---------+ C.指定pso点区间恢复(部分恢复)： 更新 name='李四' 这条数据，日志区间是Pos[1038] --> End_log_pos[1164]，按事务区间是：Pos[953] --> End_log_pos[1195]； 更新 name='小二' 这条数据，日志区间是Pos[1280] --> End_log_pos[1406]，按事务区间是：Pos[1195] --> End_log_pos[1437]； c1.单独恢复 name='李四' 这步操作，可这样： # /usr/local/mysql/bin/mysqlbinlog --start-position=1038 --stop-position=1164 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop 也可以按事务区间单独恢复，如下： # /usr/local/mysql/bin/mysqlbinlog --start-position=953 --stop-position=1195 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop c2.单独恢复 name='小二' 这步操作，可这样： # /usr/local/mysql/bin/mysqlbinlog --start-position=1280 --stop-position=1406 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop 也可以按事务区间单独恢复，如下： # /usr/local/mysql/bin/mysqlbinlog --start-position=1195 --stop-position=1437 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop c3.将 name='李四'、name='小二' 多步操作一起恢复，需要按事务区间，可这样： # /usr/local/mysql/bin/mysqlbinlog --start-position=953 --stop-position=1437 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop D.在另一终端登录查看目前结果(两名称也恢复了)： mysql> select * from zyyshop.tt; +----+----------+-----+-----+---------+ | id | name | sex | age | classid | +----+----------+-----+-----+---------+ | 1 | yiyi | w | 20 | cls1 | | 2 | 小二 | m | 22 | cls3 | | 3 | zhangsan | w | 21 | cls5 | | 4 | 李四 | m | 20 | cls4 | | 5 | wangwu | w | 26 | cls6 | +----+----------+-----+-----+---------+ E.也可指定时间区间恢复(部分恢复)：除了用pos点的办法进行恢复，也可以通过指定时间区间进行恢复，按时间恢复需要用mysqlbinlog命令读取binlog日志内容，找时间节点。 比如，我把刚恢复的tt表删除掉，再用时间区间点恢复 mysql> drop table tt; @ --start-datetime="2013-11-29 13:18:54" 起始时间点 @ --stop-datetime="2013-11-29 13:21:53" 结束时间点 # /usr/local/mysql/bin/mysqlbinlog --start-datetime="2013-11-29 13:18:54" --stop-datetime="2013-11-29 13:21:53" --database=zyyshop /usr/local/mysql/data/mysql-bin.000021 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop 总结：所谓恢复，就是让mysql将保存在binlog日志中指定段落区间的sql语句逐个重新执行一次而已。
PHP7开启Opcode性能对比
Opcache 的前生是 Optimizer+ ，它是PHP的官方公司 Zend 开发的一款闭源但可以免费使用的 PHP 优化加速组件。 Optimizer+ 将PHP代码预编译生成的脚本文件 Opcode 缓存在共享内存中供以后反复使用，从而避免了从磁盘读取代码再次编译的时间消耗。同时，它还应用了一些代码优化模式，使得代码执行更快。从而加速PHP的执行。
PHP的正常执行流程如下
request请求（nginx,apache,cli等）–>Zend引擎读取.php文件–>扫描其词典和表达式 –>解析文件–>创建要执行的计算机代码(称为Opcode)–>最后执行Opcode–> response 返回
每一次请求PHP脚本都会执行一遍以上步骤，如果PHP源代码没有变化，那么Opcode也不会变化，显然没有必要每次都重新生成Opcode，结合在Web中无所不在的缓存机制，我们可以把Opcode缓存下来，以后直接访问缓存的Opcode岂不是更快，启用Opcode缓存之后的流程图如下所示：
Opcode cache 的目地是避免重复编译，减少 CPU 和内存开销。
下面介绍Opcache的安装
安装：
1、找到opcache的扩展，我的是php7.1
yum list php71*
2、安装扩展
yum install php71w-opcache.x86_64配置：
zend_extension=opcache.so
[opcache]
;开启opcache
opcache.enable=1
;CLI环境下，PHP启用OPcache
opcache.enable_cli=1
;OPcache共享内存存储大小,单位MB
opcache.memory_consumption=128
;PHP使用了一种叫做字符串驻留（string interning）的技术来改善性能。例如，如果你在代码中使用了1000次字符串“foobar”，在PHP内部只会在第一使用这个字符串的时候分配一个不可变的内存区域来存储这个字符串，其他的999次使用都会直接指向这个内存区域。这个选项则会把这个特性提升一个层次——默认情况下这个不可变的内存区域只会存在于单个php-fpm的进程中，如果设置了这个选项，那么它将会在所有的php-fpm进程中共享。在比较大的应用中，这可以非常有效地节约内存，提高应用的性能。
这个选项的值是以兆字节（megabytes）作为单位，如果把它设置为16，则表示16MB，默认是4MB
opcache.interned_strings_buffer=8
;这个选项用于控制内存中最多可以缓存多少个PHP文件。这个选项必须得设置得足够大，大于你的项目中的所有PHP文件的总和。
设置值取值范围最小值是 200，最大值在 PHP 5.5.6 之前是 100000，PHP 5.5.6 及之后是 1000000。也就是说在200到1000000之间。
opcache.max_accelerated_files=4000
;设置缓存的过期时间（单位是秒）,为0的话每次都要检查
opcache.revalidate_freq=60
;从字面上理解就是“允许更快速关闭”。它的作用是在单个请求结束时提供一种更快速的机制来调用代码中的析构器，从而加快PHP的响应速度和PHP进程资源的回收速度，这样应用程序可以更快速地响应下一个请求。把它设置为1就可以使用这个机制了。
opcache.fast_shutdown=1
;如果启用（设置为1），OPcache会在opcache.revalidate_freq设置的秒数去检测文件的时间戳（timestamp）检查脚本是否更新。
如果这个选项被禁用（设置为0），opcache.revalidate_freq会被忽略，PHP文件永远不会被检查。这意味着如果你修改了你的代码，然后你把它更新到服务器上，再在浏览器上请求更新的代码对应的功能，你会看不到更新的效果
强烈建议你在生产环境中设置为0，更新代码后，再平滑重启PHP和web服务器。
opcache.validate_timestamps=0
;开启Opcache File Cache(实验性), 通过开启这个, 我们可以让Opcache把opcode缓存缓存到外部文件中, 对于一些脚本, 会有很明显的性能提升.
这样PHP就会在/tmp目录下Cache一些Opcode的二进制导出文件, 可以跨PHP生命周期存在.
opcache.file_cache=/tmp查看phpinfo：
测试结果：
同样的接口从以前的几百毫秒提升到现在的50ms左右
coredump文件生成样例测试源码，修改coredump大小及目录
用c编写的程序在运行出错时，系统会生成coredump文件，如果系统没有生成可以通过命令。
ulimit -c unlimited
1：添加pid作为扩展名，生成的core文件名称为core.pid
0：不添加pid作为扩展名，生成的core文件名称为core
修改 /proc/sys/kernel/core_uses_pid 文件内容为: 1
修改文件命令： echo “1” > /proc/sys/kernel/core_uses_pid
或者
sysctl -w kernel.core_uses_pid=1 kernel.core_uses_pid = 1
b. 控制core文件保存位置和文件名格式
修改文件命令： echo “/corefile/core-%e-%p-%t” > /proc/sys/kernel/core_pattern
或者：
sysctl -w kernel.core_pattern=/corefile/core-%e-%p-%t kernel.core_pattern = /corefile/core-%e-%p-%t
可以将core文件统一生成到/corefile目录下，产生的文件名为core-命令名-pid-时间戳
以下是参数列表:
%p – insert pid into filename 添加pid(进程id)
%u – insert current uid into filename 添加当前uid(用户id)
%g – insert current gid into filename 添加当前gid(用户组id)
%s – insert signal that caused the coredump into the filename 添加导致产生core的信号
%t – insert UNIX time that the coredump occurred into filename 添加core文件生成时的unix时间
%h – insert hostname where the coredump happened into filename 添加主机名
%e – insert coredumping executable name into filename 添加导致产生core的命令名
———————
作者：faithfu_yy
来源：CSDN
原文：https://blog.csdn.net/u011417820/article/details/71435031
版权声明：本文为博主原创文章，转载请附上博文链接！
1）coredump文件生成样例测试源码
使系统生成产生core文件，这样就可以利用core文件查看程序是在哪一行出现错误了，具体的方法如下：
1、程序编译时要加-g选项，保证debug信息生成在应用程序当中
2、如果运行过程中出错，执行下面命令查看程序哪里出现错误：
gdb a.out core
举例来说：
#include <stdio.h>
int main(int argc, char** argv) {
int* p = NULL;
*p = 10;
}
上面的程序会运行出错，用g++ -g编译后，生成a.out，运行a.out，产生core文件，当执行gdb a.out core时，gdb会自动停止在出错的位置。
禅道7.3升级到11.3版本，通过源代码方式升级(通用)
一、升级步骤
- 在我们 网站下载新版本的源码包，以.zip结尾。wget http://dl.cnezsoft.com/zentao/11.3/ZenTaoPMS.11.3.stable.zip
- 解压缩新的程序，覆盖到原来的目录。比如之前禅道安装的目录是在/home/wwwroot/zentao下面，则将代码覆盖到/home/wwwroot/zentao，操作方法：unzip ZenTaoPMS.11.3.stable.zip ；cd zentaopms/ 下面复制所有的文件到 /home/wwwroot/zentao下面粘帖。参考命令：rsync -azv zentaopms/ /home/wwwroot/zentao/
- 执行升级程序。假设禅道的访问路径是http://192.168.1.99/，升级路径为http://192.168.1.99/upgrade.php。
- 根据向导，选择对应的版本，按照提示进行即可。
注意：不要将原来的程序移走，再解压缩新的版本，注意是覆盖！不要拷贝成/home/wwwroot/zentao
不要下载.exe结尾的程序进行升级，那样子会覆盖原来的数据！
二、插件兼容问题
如果升级之前有安装过第三方朋友开发的插件，需要注意检查下是否和新版本的禅道兼容。如果发现升级之后无法访问，可以替换一下禅道运行代码：
1、把禅道当前运行代码文件夹改名（一般默认是 zentao 或者 zentaopms）；
2、到 禅道官网下载相同版本禅道的源码，解压后放在同目录下面，保持文件夹名字和之前禅道运行代码文件夹名称相同 。
3、把原先文件夹中的 config/my.php www/data/upload/1 www/.ztaccess www/.htaccess 拷贝到新禅道文件夹对应目录,再访问禅道试试。
version libcrypto.so.10 not defined问题？
relocation error: /usr/lib64/libssl.so.10: symbol private_ossl_minimum_dh_bits, version libcrypto.so
果断快速解决办法，从相同版本系统复制文件：
/usr/lib64/libssl.so.1.0.1e
覆盖马上恢复
cento6 下载源码升级curl到7.62.0
cento6 下载源码升级curl到7.62.0
由于业务需要，服务器上的curl 版本太老了，有漏洞，于是抽点时间升级最新版本，确保服务器间通信安全，然后网上看了些教程，发现各不相同，最后找到一个最简单，最方便的方法，分享给大家。
wget https://curl.haxx.se/download/curl-7.62.0.tar.gz
tar -zxvf curl-7.62.0.tar.gz
cd curl-7.62.0
./configure
make && make install
curl -V
FaaS选择标准：对多声道的小欲望
简单，快速的开发是人们对功能即服务（FaaS）的期望。根据我们的调查，71％使用无服务器架构的人表示，在考虑FaaS产品时，易于开发非常重要。
55％的受访者表示，在查看FaaS时，获得其主要云提供商的支持非常重要。相比之下，认为云不可知论的33％是非常重要的，并且您意识到在选择产品时，多声道几乎是事后的想法。在我们看来，这证明无服务器不会在多声道的祭坛上崇拜。
我们之前关于托管和可安装平台的文章显示了实际首选的解决方案。虽然AWS Lambda具有广泛的领先优势，但许多Azure和Google客户都渴望使用其主要云提供商的FaaS产品。我们认为，不必更换云提供商就可以让很多人无法轻松使用，因为人们可以开始使用FaaS。与用户的CI / CD管道集成同样重要。
无服务器不会在多声道的祭坛上崇拜。
不太重要的是与IDE集成，表明开发人员在创建无服务器应用程序时不需要全面的开发环境。此外，对预写功能的需求很少，因为只有16％的人表示在选择FaaS解决方案时非常重要。鉴于这些发现，我们认为云提供商不会根据专注于其FaaS产品的新产品开发工作获得许多新客户。
正如我们的“ 无服务器技术指南 ”电子书中所报告的那样，灵活扩展，节省资源成本和开发速度是人们在软件开发生命周期中看到无服务器的最积极的好处。在所有关于可移植性（跨云环境）的问题中，最不可能被引用。实际上，当用户被问及无服务器架构何时不足时，最常引用可移植性。
随着无服务器用户通过开发速度和扩展灵活性获得收益，正在牺牲可移植性和控制。
安防视频监控相关网站
常见网络摄像机默认使用的端口，RTSP地址等
常见网络摄像机默认使用的端口
常见网络摄像机的rtsp地址及相关API
常见的视频分辨率
