然后说Chrony是一个开源的自由软件是，网络时间协议(NTP)的一种通用实现， 支持Linux、 FreeBSD、 NetBSD、 macOS和Solaris系统
最后的话一般是它由两个程序组成，分别是chronyd和chronyc。chronyd是一个后台运行的守护进程，用于调整内核中运行的系统时钟和时钟服务器同步。它确定计算机增减时间的比率，并对此进行补偿。chronyc提供了一个用户界面，用于监控性能并进行多样化的配置。它可以在chronyd实例控制的计算机上工作，也可以在一台不同的远程计算机上工作什么语言实现？
+ ====== 如何在不同编程语言中实现普通时间 → Unix时间戳(Unix timestamp)？ ======
+
+ Java long epoch = new javatextSimpleDateFormat("dd/MM/yyyy HH:mm:ss")parse("01/01/1970 01:00:00");
+
+ JavaScript var commonTime = new Date(DateUTC(year, month - 1, day, hour, minute, second))
+
+ MySQL SELECT unix_timestamp(time) 时间格式: YYYY-MM-DD HH:MM:SS 或 YYMMDD 或 YYYYMMDD
+
+ Perl 先 use Time::Local 然后 my $time = timelocal($sec, $min, $hour, $day, $month, $year);
+
+ PHP mktime(hour, minute, second, day, month, year)
+
+ PostgreSQL SELECT extract(epoch FROM date('YYYY-MM-DD HH:MM:SS'));
+
+ Python 先 import time 然后 int(timemktime(timestrptime('YYYY-MM-DD HH:MM:SS', '%Y-%m-%d %H:%M:%S')))
+
+ Ruby Timelocal(year, month, day, hour, minute, second)
+
+ SQL Server SELECT DATEDIFF(s, '1970-01-01 00:00:00', time)
+
+ Unix / Linux date +%s -d"Jan 1, 1970 00:00:01"
+
+ VBScript / ASP DateDiff("s", "01/01/1970 00:00:00", time)
tcp 协议 是互联网中最常用的协议 ， 开发人员基本上天天和它打交道，对它进行深入了解。 可以帮助我们排查定位bug和进行程序优化。下面我将就TCP几个点做深入的探讨
客户端：收到 ack 后 分配连接资源。 发送数据
服务器 : 收到 syn 后立即 分配连接资源
客户端：收到ACK， 立即分配资源
服务器：收到ACK， 立即分配资源
既然三次握手也不是100%可靠， 那四次，五次，六次。。。呢 其实都一样，不管多少次都有丢包问题。
client 只发送一个 SYN， server 分配一个tcb， 放入syn队列中。 这时候连接叫 半连接 状态；如果server 收不到 client 的ACK， 会不停重试 发送 ACK-SYN 给client 。重试间隔 为 2 的 N 次方 叠加（2^0 , 2^1, 2^2 ）；直至超时才释放syn队列中的这个 TCB;
在半连接状态下， 一方面会占用队列配额资源，另一方面占用内存资源。我们应该让半连接状态存在时间尽可能的小
当client 向一个未打开的端口发起连接请求时，会收到一个RST回复包
当listen 的 backlog 和 somaxconn 都设置了得时候， 取两者min值
Recv-Q 是accept 队列当前个数， Send-Q 设置最大值
这种SYN洪水攻击是一种常见攻击方式，就是利用半连接队列特性，占满syn 队列的 资源，导致 client无法连接上。
解决方案:
为什么不像握手那样合并成三次挥手 因为和刚开始连接情况，连接是大家都从0开始， 关闭时有历史包袱的。server(被动关闭方) 收到 client(主动关闭方) 的关闭请求FIN包。 这时候可能还有未发送完的数据，不能丢弃。 所以需要分开。事实可能是这样
当然，在没有待发数据，并且允许 Delay ACK 情况下， FIN-ACK合并还是非常常见的事情，这是三次挥手是可以的。
同上
CLOSE_WAIT 是被动关闭方才有的状态 。
被动关闭方 [收到 FIN 包 发送 ACK 应答] 到 [发送FIN， 收到ACK ] 期间的状态为 CLOSE_WAIT， 这个状态仍然能发送数据。 我们叫做 半关闭 , 下面用个例子来分析:
这个是我实际生产环境碰到的一个问题，长连接会话场景，server端收到client的rpc call 请求1，处理发现请求包有问题，就强制关闭结束这次会话， 但是 因为client 发送 第二次请求之前，并没有去调用recv，所以并不知道 这个连接被server关闭， 继续发送 请求2 ， 此时是半连接，能够成功发送到对端机器，但是recv结果后，遇到连接已经关闭错误。
如果 client 和 server 恰好同时发起关闭连接。这种情况下，两边都是主动连接，都会进入 TIME_WAIT状态
1、 被动关闭方在LAST_ACK状态(已经发送FIN)，等待主动关闭方的ACK应答，但是 ACK丢掉， 主动方并不知道，以为成功关闭。因为没有TIME_WAIT等待时间，可以立即创建新的连接， 新的连接发送SYN到前面那个未关闭的被动方，被动方认为是收到错误指令，会发送RST。导致创建连接失败。
2、 主动关闭方断开连接，如果没有TIME_WAIT等待时间，可以马上建立一个新的连接，但是前一个已经断开连接的，延迟到达的数据包。 被新建的连接接收，如果刚好seq 和 ack字段 都正确, seq在滑动窗口范围内(只能说机率非常小，但是还是有可能会发生)，会被当成正确数据包接收，导致数据串包。 如果不在window范围内，则没有影响( 发送一个确认报文（ack 字段为期望ack的序列号，seq为当前发送序列号），状态变保持原样)
TIME_WAIT 问题比较比较常见，特别是CGI机器，并发量高，大量连接后段服务的tcp短连接。因此也衍生出了多种手段解决。虽然每种方法解决不是那么完美，但是带来的好处一般多于坏处。还是在日常工作中会使用。
1、改短TIME_WAIT 等待时间
这个是第一个想到的解决办法，既然等待时间太长，就改成时间短，快速回收端口。但是实际情况往往不乐观，对于并发的机器，你改多短才能保证回收速度呢，有时候几秒钟就几万个连接。太短的话，就会有前面两种问题小概率发生。
2、禁止Socket lingering
这种情况下关闭连接，会直接抛弃缓冲区中待发送的数据，会发送一个RST给对端，相当于直接抛弃TIME_WAIT， 进入CLOSE状态。同样因为取消了 TIME_WAIT 状态，会有前面两种问题小概率发生。
3、tcp_tw_reuse
netipv4tcp_tw_reuse选项是 从 TIME_WAIT 状态的队列中，选取条件：1、remote 的 ip 和端口相同， 2、选取一个时间戳小于当前时间戳； 用来解决端口不足的尴尬。
现在端口可以复用了，看看如何面对前面TIME_WAIT 那两种问题。 我们仔细回顾用一下前面两种问题。 都是在新建连接中收到老连接的包导致的问题 ， 那么如果我能在新连接中识别出此包为非法包，是不是就可以丢掉这些无用包，解决问题呢。
需要实现这些功能，需要扩展一下tcp 包头。 增加 时间戳字段。 发送者 在每次发送的时候。 在tcp包头里面带上发送时候的时间戳。 当接收者接收的时候，在ACK应答中除了TCP包头中带自己此时发送的时间戳，并且把收到的时间戳附加在后面。也就是说ACK包中有两个时间戳字段。结构如下:
那我们接下来一个个分析tcp_tw_reuse是如何解决TIME_WAIT的两个问题的
4、tcp_tw_recycle
tcp_tw_recycle 也是借助 timestamp机制。顾名思义， tcp_tw_reuse 是复用 端口，并不会减少 TIME-WAIT 数量。你去查询机器上TIME-WAIT 数量，还是 几千几万个，这点对有强迫症的同学感觉很不舒服。tcp_tw_recycle 是 提前 回收 TIME-WAIT资源。会减少 机器上 TIME-WAIT 数量。
tcp_tw_recycle 工作原理是。
一、 使用mysql相关命令进行简单的本地备份1 mysqlldump命令
mysqldump 是采用SQL级别的备份机制，它将数据表导成 SQL 脚本文件，在不同的 MySQL 版本之间升级时相对比较合适，这也是最常用的备份方法。
使用 mysqldump进行备份非常简单，如果要备份数据库” db_backup ”,使用命令：
#mysqldump –u -p phpbb_db_backup > /usr/backups/mysql/db_backup2008-1-6sql
还可以使用gzip命令对备份文件进行压缩：
#mysqldump db_backup | gzip > /usr/backups/mysql/ db_backup2008-1-6sqlgz (备份后生成的sql不含建库语句！)
只备份一些频繁更新的数据库表：
## mysqldump sample_db articles comments links > /usr/backups/mysql/sample_dbart_comm_lin2008-1-6sql
上面的命令会备份articles, comments, 和links 三个表。
恢复数据使用命令：
#mysql –u -p db_backup </usr/backups/mysql/ db_backup2008-1-6sql
注意使用这个命令时必须保证数据库正在运行。
2 使用 SOURCE 语法
其实这不是标准的 SQL 语法，而是 mysql 客户端提供的功能，例如：
# SOURCE /tmp/db_namesql;
这里需要指定文件的绝对路径，并且必须是 mysqld 运行用户(例如 nobody)有权限读取的文件。
3 mysqlhotcopy备份
mysqlhotcopy 只能用于备份 MyISAM，并且只能运行在 linux 和Unix 和 NetWare 系统上。mysqlhotcopy 支持一次性拷贝多个数据库，同时还支持正则表达。以下是几个例子：
#mysqlhotcopy -h=localhost -u=goodcjh -p=goodcjh db_name /tmp
(把数据库目录 db_name 拷贝到 /tmp 下)
注意，想要使用 mysqlhotcopy，必须要有 SELECT、RELOAD(要执行 FLUSH TABLES) 权限，并且还必须要能够有读取 datadir/db_name 目录的权限。
还原数据库方法：
mysqlhotcopy 备份出来的是整个数据库目录，使用时可以直接拷贝到 mysqld 指定的 目录 (在这里是 /usr/local/mysql/data/)目录下即可，同时要注意权限的问题，另外首先应当删除数据库旧副本如下例：
# /bin/rm -rf /mysql-backup///old
关闭mysql 服务器、复制文件、查询启动mysql服务器的三个步骤：
# /etc/initd/mysqld stop
Stopping MySQL: [ OK ]
# cp -af /mysql-backup/// /var/lib/mysql /
# /etc/initd/mysqld start
Starting MySQL: [ OK ]
#chown -R nobody:nobody /usr/local/mysql/data/ (将 db_name 目录的属主改成 mysqld 运行用户)
二、使用网络备份
将MYSQL数据放在一台计算机上是不安全的，所以应当把数据备份到局域网中其他Linux计算机中。假设Mysql服务器IP地址是：19216813。局域网使用Linux的远程计算机IP地址是19216814；类似于windows的网络共享，UNIX(Linux)系统也有自己的网络共享，那就是NFS(网络文件系统)，在linux客户端挂接(mount)NFS磁盘共享之前，必须先配置好NFS服务端。linux系统NFS服务端配置方法如下：
(1)修改 /etc/exports,增加共享目录
/export/home/sunky 19216814(rw)
/export/home/sunky1 (rw)
/export/home/sunky2 linux-client(rw)
注：/export/home/目录下的sunky、sunky1、sunky2是准备共享的目录，1014013323、、linux-client是被允许挂接此共享linux客户机的IP地址或主机名。如果要使用主机名linux-client必须在服务端主机/etc/hosts文件里增加linux-client主机ip定义。格式如下：
19216814 linux-client
若修改/etc/export文件增加新的共享，应先停止NFS服务，再启动NFS服务方能使新增加的共享起作用。使用命令exportfs -rv也可以达到同样的效果。linux客户端挂接(mount)其他linux系统或UNIX系统的NFS共享。这里我们假设19216814是NFS服务端的主机IP地址，当然这里也可以使用主机名，但必须在本机/etc/hosts文件里增加服务端ip定义。/export/home/sunky为服务端共享的目录。如此就可以在linux客户端通过/mnt/nfs来访问其它linux系统或UNIX系统以NFS方式共享出来的文件了。
把MYSQL数据备份到使用Linux的远程计算机需要在两端都安装NFS协议（Network File System），远程NFS计算机安装NFS协议后还要修改配置文件：/etc/exports,加入一行：
/usr/backups/mysql/ 19216814 (rw, no_root_squash)
表示将/usr/backups/mysql/目录共享。这个目录具有远程root用户读写权限。保存NFS配置文件，然后使用命令：
#exportfs -a –r
然后重新启动NFS服务：
#service nfsd start
远程计算机设定后，在MYSQL服务器/mnt 目录下建立一个backup_share目录：
#mkdir /mnt/backup_share
将远程的Linux计算机的/usr/backups/mysql/目录挂载到MYSQL服务器的/mnt/backup_share目录下：
# mount -t nfs 19216814：/usr/backups/mysql /mnt/backup_share
将目录挂载进来后，只要进入/mnt/backup_share 目录，就等于到了IP地址：19216814那部NFS 计算机的/usr/backups/mysql 目录中。下面使用mysqldump把“phpbb_db_backup”备份到远程计算机：
# mysqldump db_backup > /mnt/backup_share/ db_backup2008-1-6sql
自动完成网络备份的方法：
Linux 服务器上的程序每天都在更新 MySQL 数据库，于是就想起写一个 shell 脚本，结合 crontab，定时备份数据库。建立一个shell脚本：sample_db_backupsh
# At the very end the $(date +%F) 自动添加备份日期
mysqldump -u <username> -p <password> -h <hostname> sample_db > /mnt/backup_share/sample_db$(date +%F)
#un-mount the filesystem
umount /mnt/backup_share
# mount \u2013o soft 19216814:/archive /mnt/backup_share
说明：mount NFS服务器的一个重要参数：hard （硬） mount或soft（软）mount。
硬挂载: NFS客户机会不断的尝试与NFS服务器的连接（在后台，一般不会给出任何提示信息），直到挂载上为止。
软挂载:会在前台尝试与NFS服务器的连接，是默认的连接方式。当收到错误信息后终止mount尝试，并给出相关信息。
对于到底是使用硬挂载还是软挂载的问题，这主要取决于你访问什么信息有关。例如你是想察看NFS服务器的视频文件时，你绝对不会希望由于一些意外的情况（如网络速度一下子变的很慢）而使系统输出大量的错误信息，如果此时你用的是硬挂载方式的话，系统就会等待，直到能够重新与NFS 服务器建立连接传输信息。另外如果是非关键数据的话也可以使用软挂载方式，如FTP一些数据等，这样在远程机器暂时连接不上或关闭时就不会挂起你的会话过程。
下面建立脚本文件权限：chmod +x /sample_db_backupsh
然后使用将此脚本加到 /etc/crontab 定时任务中：
01 5 0 mysql /home/mysql/ sample_db_backupsh
好了，每周日凌晨 5:01 系统就会自动运行 sample_db_backupsh 文件通过网络备份 MySQL 数据库了。
三、实时恢复M y S Q L数据方法
在对MySQL数据和表格结构进行备份时，mysqldump是一个非常有用的工具。然而，通常情况下，一般一天只备份一次，或者在一个特定的间隔备份一次。如果在刚备份完成的一段时间以内数据丢失，那么这些数据很有可能无法恢复。有什么方法可以对数据进行实时性地保护呢事实上，现在有几种方法都可以实现MySQL数据库的实时保护。这里介绍其中一种，即使用二进制日志进行数据恢复。
1 设置二进制日志方法
要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。一般可以从选项文件(即mycnf or myini，取决于你的系统)中找到路径。如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。启用二进制日志的选项为-- log-bin。要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：
# SHOW BINLOG EVENTS \G
2 最简单的数据恢复
每天备份和运行二进制日志的确是一个在MySQL服务器中恢复数据的不错方法。比如，可以每天在深夜使用mysqldump对数据进行备份，如果某天在数据备份完成后的一段时间里，由于某种原因数据丢失，可以使用以下方法来对其进行恢复。首先，停止MySQL服务器，然后使用以下命令重新启动MySQL服务器。该命令将保证是惟一可以访问该数据库服务器的人：
# /etc/initd/mysqld stop
Stopping MySQL: [ OK ]
# mysqld --socket=/tmp/mysql_restoresock --skip-networking
这里， 一socket选项将为U n i x 系统命名一个不同的Socket文件。一旦服务器处于独占控制之下，就可以放心地对数据库进行 *** 作，而不用担心在进行数据恢复的过程中有用户尝试访问数据库而导致更多的麻烦。进行恢复的第一个步骤是恢复晚上备份好的dump文件：
#mysql -u root -pmypwd --socket=/tmp/mysql_restoresock < /var/backup/20080120sql
该命令可以将数据库的内容恢复至晚上刚刚完成备份的内容。要恢复dump文件创建后的数据库事务处理， 可以使用mysqlbinlog工具。如果每天晚上进行备份 *** 作时都对日志进行flush *** 作，则可以使用以下命令行工具将整个二进制日志文件进行恢复：
mysqlbinlog /var/log/mysql/bin123456 \
| mysql -u root -pmypwd --socket=/tmp/mysql_restoresock
3 针对某一时问点的恢复
对于MySQL 414，可以在mysqlbinlog语句中通过--start-date和--stop-date选项指定DATETIME格式的起止时间。假设用户在2008-1-22上午10点执行的SQL语句删除了一个大的数据表，则可以使用以下命令进行恢复：要想恢复表和数据，你可以恢复前晚上的备份，并输入：
#mysqlbinlog --stop-date="2008-1-22 9:59:59"
/var/log/mysql/bin123456 |
mysql -u root -pmypwd \
--socket=/tmp/mysql_restoresock
#mysql -u root -pmypwd
该语句将恢复所有给定一stop-date日期之前的数据。如果在执行某SQL语句数小时之后才发现执行了错误 *** 作，那么可能还需要恢复之后输入的一些数据。这时， 也可以通过mysqlbinlog来完成该功能：
#mysqlbinlog --start-date="2008-1-22 10:01:00" \
/var/log/mysql/bin123456 \
| mysql -u root -pmypwd \
--socket=/tmp/mysql_restoresock
#mysql -u root -pmypwd
在该行中，从上午10:01登录的SQL语句将运行。组合执行前夜的转储文件和mysqlbinlog的两行可以将所有数据恢复到上午10:00前一秒钟。你应检查日志以确保时间确切。
4 使用Position进行恢复
也可以不指定日期和时间，而使用mysqlbinlog的选项--start-position和--stop-position来指定日志位置。它们的作用与起止日选项相同，不同的是给出了从日志起的位置号。使用日志位置是更准确的恢复方法，特别是当由于破坏性SQL语句同时发生许多事务的时候。要想确定位置号，可以运行mysqlbinlog寻找执行了不期望的事务的时间范围，但应将结果重新指向文本文件以便进行检查。 *** 作命令为：
mysqlbinlog --start-date="2005-04-20 9:55:00" --stop-date="2005-04-20 10:05:00"
/var/log/mysql/bin123456 > /tmp/mysql_restoresql
该命令将在/tmp目录创建小的文本文件，将显示执行了错误的SQL语句时的SQL语句。你可以用vi或者gedit文本编辑器打开该文件，寻找你不要想重复的语句。如果二进制日志中的位置号用于停止和继续恢复 *** 作，应进行注释。用log_pos加一个数字来标记位置。使用位置号恢复了以前的备份文件后，你应从命令行输入下面内容：
mysqlbinlog --stop-position="368312" /var/log/mysql/bin123456
| mysql -u root -pmypwd
mysqlbinlog --start-position="368315" /var/log/mysql/bin123456
| mysql -u root -pmypwd
上面的第1行将恢复到停止位置为止的所有事务。下一行将恢复从给定的起始位置直到二进制日志结束的所有事务。因为mysqlbinlog的输出包括每个SQL语句记录之前的SET TIMESTAMP语句，恢复的数据和相关MySQL日志将反应事务执行的原时间。会不会是本地的环境和linux服务器的环境不同引起的，比如php mysql 版本之类的本地和服务器上面的不一样CURRENT_TIMESTAMP 好像要mysql56之后才可以用，另外你说linux服务器后，执行没反应，会不会是这个文件压根就没执行，还有就是你可以把服务器上的报错打开，执行到如果有问题的话会有报错的
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）