Reprint

Uboot https://www.jianshu.com/p/42106ed7cbde 我们知道,bootloader是系统上电后最初加载运行的代码。它提供了处理器上电复位后最开始需要执行的初始化代码。 在PC机上引导程序一般由BIOS开始执行,然后读取硬盘中位于MBR(Main Boot Record,主引导记录)中的Bootloader(例如LILO或GRUB),并进一步引导操作系统的启动。 然而在嵌入式系统中通常没有像BIOS那样的固件程序,因此整个系统的加载启动就完全由bootloader来完成。它主要的功能是加载与引导内核映像 一个嵌入式的存储设备通过通常包括四个分区: 第一分区: 存放的当然是u-boot 第二个分区: 存放着u-boot要传给系统内核的参数 第三个分区: 是系统内核 (kernel) 第四个分区: 则是根文件系统 如下图所示: 四大分区 u-boot是一种普遍用于嵌入式系统中的Bootloader。 Bootloader介绍 Bootloader是进行嵌入式开发必然会接触的一个概念,本篇文章主要讲解Bootloader的基本概念以及内部原理,这部分内容的掌握将对嵌入式linux系统开发的学习非常有帮助！ Bootloader的定义: Bootloader是在操作系统运行之前执行的一小段程序,通过这一小段程序,我们可以初始化硬件设备、建立内存空间的映射表,从而建立适当的系统软硬件环境,为最终调用操作系统内核做好准备。意思就是说如果我们要想让一个操作系统在我们的板子上运转起来,我们就必须首先对我们的板子进行一些基本配置和初始化,然后才可以将操作系统引导进来运行。具体在Bootloader中完成了哪些操作我们会在后面分析到,这里我们先来回忆一下PC的体系结构: PC机中的引导加载程序是由BIOS和位于硬盘MBR中的OS Boot Loader (比如LILO和GRUB等) 一起组成的,BIOS在完成硬件检测和资源分配后,将硬盘MBR中的Boot Loader读到系统的RAM中,然后将控制权交给OS Boot Loader。Boot Loader的主要运行任务就是将内核映象从硬盘上读到RAM中,然后跳转到内核的入口点去运行,即开始启动操作系统。在嵌入式系统中,通常并没有像BIOS那样的固件程序 (注: 有的嵌入式cpu也会内嵌一段短小的启动程序) ,因此整个系统的加载启动任务就完全由Boot Loader来完成。比如在一个基于ARM7TDMI core的嵌入式系统中,系统在上电或复位时通常都从地址0x00000000处开始执行,而在这个地址处安排的通常就是系统的Boot Loader程序。 (先想一下,通用PC和嵌入式系统为何会在此处存在如此的差异呢？) Bootloader是基于特定硬件平台来实现的,因此几乎不可能为所有的嵌入式系统建立一个通用的Bootloader,不同的处理器架构都有不同的Bootloader,Bootloader不但依赖于cpu的体系结构,还依赖于嵌入式系统板级设备的配置。对于2块不同的板子而言,即使他们使用的是相同的处理器,要想让运行在一块板子上的Bootloader程序也能运行在另一块板子上,一般也需要修改Bootloader的源程序。 Bootloader的启动方式 Bootloader的启动方式主要有网络启动方式、磁盘启动方式和Flash启动方式。 网络启动方式 如图1所示,里面主机和目标板,他们中间通过网络来连接,首先目标板的DHCP/BIOS通过BOOTP服务来为Bootloader分配IP地址,配置网络参数,这样才能支持网络传输功能。我们使用的u-boot可以直接设置网络参数,因此这里就不用使用DHCP的方式动态分配IP了。接下来目标板的Bootloader通过TFTP服务将内核映像下载到目标板上,然后通过网络文件系统来建立主机与目标板之间的文件通信过程,之后的系统更新通常也是使用Boot Loader的这种工作模式。工作于这种模式下的Boot Loader通常都会向它的终端用户提供一个简单的命令行接口。 磁盘启动方式 这种方式主要是用在台式机和服务器上的,这些计算机都使用BIOS引导,并且使用磁盘作为存储介质,这里面两个重要的用来启动linux的有LILO和GRUB,这里就不再具体说明了。 Flash启动方式 这是我们最常用的方式。Flash有NOR Flash和NAND Flash两种。NOR Flash可以支持随机访问,所以代码可以直接在Flash上执行,Bootloader一般是存储在Flash芯片上的。另外Flash上还存储着参数、内核映像和文件系统。这种启动方式与网络启动方式之间的不同之处就在于,在网络启动方式中,内核映像和文件系统首先是放在主机上的,然后经过网络传输下载进目标板的,而这种启动方式中内核映像和文件系统则直接是放在Flash中的,这两点在我们u-boot的使用过程中都用到了。 U-boot的定义 U-boot,全称Universal Boot Loader,是由DENX小组的开发的遵循GPL条款的开放源码项目,它的主要功能是完成硬件设备初始化、操作系统代码搬运,并提供一个控制台及一个指令集在操作系统运行前操控硬件设备。U-boot之所以这么通用,原因是他具有很多特点: 开放源代码、支持多种嵌入式操作系统内核、支持多种处理器系列、较高的稳定性、高度灵活的功能设置、丰富的设备驱动源码以及较为丰富的开发调试文档与强大的网络技术支持。另外u-boot对操作系统和产品研发提供了灵活丰富的支持,主要表现在: 可以引导压缩或非压缩系统内核,可以灵活设置/传递多个关键参数给操作系统,适合系统在不同开发阶段的调试要求与产品发布,支持多种文件系统,支持多种目标板环境参数存储介质,采用CRC32校验,可校验内核及镜像文件是否完好,提供多种控制台接口,使用户可以在不需要ICE的情况下通过串口/以太网/USB等接口下载数据并烧录到存储设备中去 (这个功能在实际的产品中是很实用的,尤其是在软件现场升级的时候) ,以及提供丰富的设备驱动等。 u-boot源代码的目录结构 board中存放于开发板相关的配置文件,每一个开发板都以子文件夹的形式出现。 Commom文件夹实现u-boot行下支持的命令,每一个命令对应一个文件。 cpu中存放特定cpu架构相关的目录,每一款cpu架构都对应了一个子目录。 Doc是文档目录,有u-boot非常完善的文档。 Drivers中是u-boot支持的各种设备的驱动程序。 Fs是支持的文件系统,其中最常用的是JFFS2文件系统。 Include 文件夹是 u-boot 使用的头文件, 还有各种硬件平台支持的汇编文件,系统配置文件和文件系统支持的文件。 ...

pandavan # restart dnsmasq restart_dhcpd

arp command ARP 协议概述 IP 数据包常通过以太网发送。以太网设备并不识别32位IP地址: 它们是以48位以太网地址传输以太网数据包的。因此,IP驱动器必须把IP目的地址转换成以太网网目的地址。在这两种地址之间存在着某种静态的或算法的映射,常常需要查看一张表。地址解析协议(Address Resolution Protocol,ARP)就是用来确定这些映象的协议。 ARP工 作时,送出一个含有所希望的IP地址的以太网广播数据包。目的地主机,或另一个代表该主机的系统,以一个含有IP和以太网地址对的数据包作为应答。发送者将这个地址对高速缓存起来,以节约不必要的ARP通信。 https://www.ibm.com/developerworks/cn/linux/l-arp/index.html pacman -S core/net-tools # mac ip mapping arp -a

MySQL count 性能 https://blog.csdn.net/kjsoftware/article/details/76762208 COUNT()的作用 COUNT()是一个特殊的函数,有两种非常不同的作用: 它可以统计某个列值的数量,也可以统计行数。在统计列值时要求列值时非空的 (不统计NULL) 。如果在COUNT()的括号中指定了列或列的表达式,统计的就是这个表达式有值的结果数。因为很多人对NULL理解有问题,所以这里很容易产生误解。如果想了解更多关于SQL语句中NULL的含义,建议阅读一些关于SQL语句基础的书籍。 (关于这个话题,互联网上的一些信息是不够精确的) COUNT()的另外一个作用是统计结果集的行数。当MySQL确认括号内的表达式值不可能为空时,实际上就是在统计行数。最简单的就是当我们使用COUNT(_)的时候,这种情况下通配符_并不会像我们猜想的那样扩展成所有的列,实际上,它会忽略所有的列而直接统计所有的行数。 我们发现一个最常见的错误就是,在括号内指定了一个列却希望统计结果集的行数。如果希望知道的是结果集的行数,最好使用COUNT(*),这样写意义清晰,性能也会很好。 于MyISAM的神话 一个容易产生的误解就是: MyISAM的COUNT()函数总是非常快,不过这是有前提条件的,即只有没有任何where条件的COUNT()才非常快,因为此时无需实际地去计算表的行数。MySQL可以利用存储引擎的特性直接获得这个值。如果MySQL知道某列col不可能为NULL值,那么MySQL内部会将COUNT(col)表达式优化为COUNT()。 当统计带WHERE子句的结果集行数,可以是统计某个列值的数量时,MySQL的COUNT()和其它存储引擎没有任何不同,就不再有神话般的速度了。所以在MyISAM引擎表上执行COUNT()有时候比别的引擎快,有时候比别的引擎慢,这受很多因素影响,要视具体情况而定。 《高性能MySQL》这本书只介绍了MyISAM存储引擎在count上的误区以及在MyISAM存储引擎上的count优化,而对于常用的innodb执行Count没有做过多讲解,下面我们就聊聊如何在Innodb上进行count优化。 Innodb存储引擎: (1) innodb存储引擎的物理结构包含 表空间、段、区、页、行 五个层级,数据文件按照主键排序存储在页中 (页在逻辑上连续) ,主键的位置即为数据存储位置。 (2) 二级索引存储的数据为指定字段的值与主键值。当我们通过二级索引统计数据的时候,无需扫描数据文件；而通过主键索引统计数据时,由于主键索引与数据文件存放在一起,所以每次都会扫描数据文件,故大多数情况下,通过二级索引统计数据效率 >= 基于主键统计效率。 (3) 由于二级索引存储的数据为指定字段的值与主键值,故在无索引覆盖的情况下,查询二级索引后会根据二级索引获取的主键到主键索引中提取数据,此过程可能造成大量的随机io,导致查询速度较慢。 (4) 由于主键索引与数据存储保持一致,故基于主键的查找数据要比通过二级索引查询数据要快 (使用二级索引时,查询到的数据条数>总条数的20%时候MySQL就选择全表扫描,但在主键索引上,即使符合条件的达到 90%依然会走索引) 。 count慢的原因: innodb为聚簇索引同时支持事物,其在count指令实现上采用实时统计方式。在无可用的二级索引情况下,执行count会使MySQL扫描全表数据,当数据中存在大字段或字段较多时候,其效率非常低下 (每个页只能包含较少的数据条数,需要访问的物理页较多) 。 innodb可优化点: 主键需要采用占用空间尽量小的类型且数据具有连续性 (推荐自增整形id) ,这样有利于减少页分裂、页内数据移动,可加快插入速度同时有利于增加二级索引密度 (一个数据页上可以存储更多的数据) 。 2.在表包含大字段或字段较多情况下,若存在count统计需求,可建一个较小字段的二级索引 (例 char(1) , tinyint )来进行count统计加速。 下面做个count优化例子: 1.首先我们创建一直innodb表,并包含大字段 (或包含较多字段) : CREATE TABLE qstardbcontent ( id BIGINT(20) NOT NULL DEFAULT ‘0’, content MEDIUMTEXT, length INT(11) NOT NULL DEFAULT ‘0’, PRIMARY KEY (id) ...

MySQL 聚簇索引 https://yq.aliyun.com/articles/142879 https://blog.csdn.net/bigtree_3721/article/details/51335479 因为存储引擎负责实现索引,因此不是所有的存储引擎都支持聚簇索引。 一些数据库服务器允许选择哪个索引作为聚簇索引,但直到本书写作之前,还没有任何一个MySQL内建的存储引擎支持这一点。InnoDb将通过主键聚集数据。 如果没有定义主键,InnoDB 会选择一个唯一的非空索引代替。如果没有这样的索引,InnoDB 会隐式定义一个主键来作为聚簇索引。InnoDB值聚集在同一个页面中的记录。包含相邻键值的页面可能会相距很远。 聚簇索引可能对性能有帮助,但也可能导致严重的性能问题。所以需要考虑聚簇索引,尤其是将表的存储引擎从InnoDB 该成其他的引擎的时候 (返回来也一样) 。 数据访问更快。聚簇索引将索引和数据保存在同一个B-Tree中,因此从聚簇索引中获取数据通常比非聚簇索引中快。 二级索引 (非聚簇索引) 可能比想象的要更大,因为在二级索引的子节点包含了最优一个几点可能让人有些疑惑,为什么二级索引需要两次索引查找？答案在于二级索引中保存的"行指针"的实质。要记住,二级索引叶子节点保存的不是只想物理位置的指针,而是行的主键值。 InnoDB 的数据分布。因为InnoDB支持聚簇索引,索引使用非常不同的方式存储同样的数据。在InnoDB中,聚簇索引"就是"表,所以不像myISAM那样需要独立的行存储。聚簇索引的每一个叶子节点都包含了主键值、事务id,用于事务和MVCC的回滚指针。这样的策略减少了当前出现行移动或者数据页分裂是二级索引的维护工作。使用主键值当作指针会让二级索引占用更多的存储空间,存储,换来的好处是,InnoDB在移动行时,无需更新二级索引中的这个指针。InnoDB 的非叶子节点包含了索引列和一个纸箱下级节点的指针 (下级节点可以是叶子节点,也可以是非叶子节点) 。这对聚簇索引和二级索引都使用。 聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。相比之下,聚簇索引适合排序,非聚簇索引 (也叫二级索引) 不适合用在排序的场合。 因为聚簇索引本身已经是按照物理顺序放置的,排序很快。非聚簇索引则没有按序存放,需要额外消耗资源来排序。 当你需要取出一定范围内的数据时,用聚簇索引也比用非聚簇索引好。 另外,二级索引需要两次索引查找,而不是一次才能取到数据,因为存储引擎第一次需要通过二级索引找到索引的叶子节点,从而找到数据的主键,然后在聚簇索引中用主键再次查找索引,再找到数据。 辅助索引 在聚簇索引之上创建的索引称之为辅助索引,辅助索引访问数据总是需要二次查找。辅助索引叶子节点存储的不再是行的物理位置,而是主键值。通过辅助索引首先找到的是主键值,再通过主键值找到数据行的数据叶,再通过数据叶中的Page Directory找到数据行。 复合索引 由多列创建的索引称为符合索引,在符合索引中的前导列必须出现在where条件中,索引才会被使用 前缀索引 当索引的字符串列很大时,创建的索引也就变得很大,为了减小索引体积,提高索引的扫描速度,就用索引的前部分字串索引,这样索引占用的空间就会大大减少,并且索引的选择性也不会降低很多。而且是对BLOB和TEXT列进行索引,或者非常长的VARCHAR列,就必须使用前缀索引,因为MySQL不允许索引它们的全部长度。 使用: 列的前缀的长度选择很重要,又要节约索引空间,又要保证前缀索引的选择性要和索引全长度选择性接近。 唯一索引 唯一索引比较好理解,就是索引值必须唯一,这样的索引选择性是最好的 主键索引 主键索引就是唯一索引,不过主键索引是在创建表时就创建了,唯一索引可以随时创建。 说明 主键和唯一索引区别 主键是主键约束+唯一索引 主键一定包含一个唯一索引,但唯一索引不是主键 唯一索引列允许空值,但主键列不允许空值 一个表只能有一个主键,但可以有多个唯一索引

聚合函数 aggregation function, UNION, UNION ALL 聚合函数 (aggregation function) -也就是组函数 在一个行的集合 (一组行) 上进行操作,对每个组给一个结果。 集合查询操作 union 去重 union用于把两个或者多个select查询的结果集合并成一个 默认情况下,UNION = UNION DISTINCT 进行合并的两个查询,其SELECT列表必须在数量和对应列的数据类型上保持一致; 默认会去掉两个查询结果集中的重复行；默认结果集不排序； 最终结果集的列名来自于第一个查询的SELECT列表 union all 不去重 UNION ALL 不去掉结果集中重复的行 SELECT ... UNION [ALL | DISTINCT] SELECT ... [UNION [ALL | DISTINCT] SELECT ...] 常用的组函数: AVG([distinct] expr) 求平均值 COUNT({*|[distinct] } expr) 统计行的数量 MAX([distinct] expr) 求最大值 MIN([distinct] expr) 求最小值 SUM([distinct] expr) 求累加和 ①每个组函数接收一个参数 ②默认情况下,组函数忽略列值为null的行,不参与计算 ③有时,会使用关键字distinct剔除字段值重复的条数 注意: 当使用组函数的select语句中没有group by子句时,中间结果集中的所有行自动形成一组,然后计算组函数； 组函数不允许嵌套,例如: count(max(…))； 组函数的参数可以是列或是函数表达式； ...

nftable 透明代理 https://www.yangcs.net/posts/linux-circumvent/

svn change passwd svn change password after svn password changed, delete the folder $HOME/.subversion run svn checkout -username user svn://server/repo, input new password run git svn

systemd-networkd MAC address spoofing vim /etc/systemd/network/00-default.link [Match] MACAddress=old mac address [Link] MACAddress=new mac address NamePolicy=kernel database onboard slot path NamePolicy 应该如何设置网卡的名称, 仅在未使用 “net.ifnames=0” 内核引导选项时有意义。 接受一个空格分隔的策略列表, 顺序尝试每个策略,并以第一个成功的策略为准。 所得的名字将被用于设置网卡的 “ID_NET_NAME” 属性。 注意,默认的udev规则会用 “ID_NET_NAME” 的值设置 “NAME” 属性(也就是网卡的名称)。 如果网卡已经被空户空间命名,那么将不会进行任何重命名操作。 可用的策略如下: kernel 如果内核已经为此网卡设置了固定的可预测名称, 那么不进行任何重命名操作。 database 基于网卡的 “ID_NET_NAME_FROM_DATABASE” 属性值(来自于udev硬件数据库)设置网卡的名称。 onboard 基于网卡的 “ID_NET_NAME_ONBOARD” 属性值(来自于板载网卡固件)设置网卡的名称。 slot 基于网卡的 “ID_NET_NAME_SLOT” 属性值(来自于可插拔网卡固件)设置网卡的名称。 path 基于网卡的 “ID_NET_NAME_PATH” 属性值(来自于网卡的总线位置)设置网卡的名称。 mac 基于网卡的 “ID_NET_NAME_MAC” 属性值(来自于网卡的固定MAC地址)设置网卡的名称。 windows mac address windows 的无线网卡不支持直接修改 mac 地址，虽然可以通过修改注册表实现修改但是mac地址第二位只能修改为 2, 6, A, E 其中的一个， 改成其它值都不会生效。 ...

MySQL 在线修改表结构 http://www.cnblogs.com/wangtao_20/p/3504395.html MySQL在线修改表结构大数据表的风险与解决办法归纳 整理这篇文章的缘由: 互联网应用会频繁加功能,修改需求。那么表结构也会经常修改,加字段,加索引。在线直接在生产环境的表中修改表结构,对用户使用网站是有影响。 以前我一直为这个问题头痛。当然那个时候不需要我来考虑,虽然我们没专门的dba,他们数据量比我们更大,那这种问题也会存在。所以我很想看看业界是怎么做的,我想寻找有没有更高级的方案,呵呵,让我觉得每次开发一个新功能,我在线加字段都比较纠结。后来只知道,不清楚在什么时候,无意中看到一个资料介绍online-schema-change这个工具,于是顺便搜出了不少东西。后来逐渐发现腾讯,淘宝他们都会存在这种问题,我发现解决思路都差不多。具体看完我这篇归纳的文章 由于MySQL在线ddl(加字段、加索引等修改表结构之类的操作) 过程如下: A.对表加锁(表此时只读) B.复制原表物理结构 C.修改表的物理结构 D.把原表数据导入中间表中,数据同步完后,锁定中间表,并删除原表 E.rename中间表为原表 F.刷新数据字典,并释放锁 在这个过程中会锁表。造成当前操作的表无法写入数据,影响用户使用。由于需要复制原表的数据到中间表,所以表的数据量越大,等待的时候越长,卡死在那里(用户被拒绝执行update和insert操作,表现就是延迟了一直在等待)。 其实就是对表加了个排它锁,这个时候其他用户只能读表的数据,不能写。想具体体验一下是什么效果,我以前测验对MySQL的表加锁,操作的时候是如何的: http://www.cnblogs.com/wangtao_20/p/3463435.html 平时进行修改表的结构,更改字段,新增字段,更改字段名称一般都是通过ALTER TABLE TABLENAE 语法进行修改的。对于测试库,在线小表或者并发访问不是很大的情况是OK。但是如果是在线大表。那就很麻烦。由于表数据量大,复制表需要比较长的时间,在这个时间段里面,表是被加了锁的(写锁),加写锁时其他用户只能select表不能update、insert表。表数据量越大,耗时越长。 所以,对于数据量大的表,数量很大。在线修改表结构一直是一个头痛的问题,因为互联网应用的一大特点不能影响用户正常使用,否则用户会慢慢流失掉。 有些公司碰到的表数据很小,几万到几十万行数据一张表,可能还不会遇到应用卡死的问题。所以我们网站在跑,开发个新功能,需要加个新字段,经常是直接操作不会影响什么(何况只是延迟写入操作而已,呵呵) 看这几篇文章就知道了: http://wiki.hexnova.com/pages/viewpage.action?pageId=2031684 MySQL在线修改表字段造成的锁表 http://hidba.org/?p=795 比如就有人专门在加字段之前进行测验MySQL是否复制表,以减低应用卡死的风险: http://www.cnblogs.com/zuoxingyu/archive/2013/03/28/2986715.html 拷贝表结构,然后插入少量的数据。去修改表结构。看影响的行。如果为0,则表示不会拷贝中间表的方式 目前业界实践出了一些成熟的解决办法: 很多公司以前的做法是: 停掉MySQL服务器来修改表结构。然后进行滚动式更新。比如很多台MySQL服务器。先修改主服务器的表结构,把这台服务器停掉来更新(一般多台主服务器,让其他主服务器提供服务)。等到更新完,就滚动到从服务器(在此之前是其他从服务器提供服务的)。其实想想发现有个弊病: 修改表结构要等到很长时间才能生效。MySQL服务器越多,就需要的时间越长。那我可以理解: 假设需要几天,那只有等到更新完毕。才能把代码丢上去,因为表结构没有更新完毕,新的程序操作新的字段会出错的。 从冯大辉那篇文章那里听说,Facebook数千台MySQL服务器在过去增加个索引需要几个月的滚动升级(后来他们自己开发了后面提到的工具,只需要几天) 能够停掉MySQL服务器来修改字段,这就好办,时间长也无所谓,呵呵,至少用户不会使用你网站的时候卡死吧。但是互联网应用往往不能影响用户使用,所以很多公司尽量是在凌晨的时候进行操作(这个时候访问用户少,对用户影响就小) 比如像这个例子: http://www.MySQLops.com/2011/03/30/myisam-innodb.html 表的数据量上亿。要把表的存储引擎从myisam改为innodb(我觉得存储结构都不同了,转换需要时间更长),但是他是停掉MySQL服务器操作的。 阿里巴巴的冯大辉分享中也提到,业务应用大,需求就会频繁变化。所以就经常涉及到修改数据库字段,在线的调整字段是要考虑很多的问题的。作者认为,目前没有特别的方法来解决这个问题(技术是适应需求变化,支撑运营的)。他说豆瓣对此也很头痛,只能把服务器短暂的停一下。 测验法。加字段,加索引,先在测试环境模拟测试一下需要多长时间。免得服务器生产环境正式加的时候,应用卡死了,好有个预期准备。 我记得以前在a公司,表数据量也上千万,压根就没这种测验吧,大白天,就直接加字段和索引,反正我也不知道前台影响如何,当时我也没这个经验,何况我也不是技术负责人,呵呵,技术负责人都没不清楚这个,我那就更加没了,那个技术经理是做企业级开发的,跟web开发环境和思维方式是不同的,他不清楚会存在这些影响吧,再说,当时在加的时候没法凑巧用户投诉说,网站无法下单了啊,没这么巧的情况。其实从我现在理解角度来看,我绝对会更加严格点。 前面也提到了,国外有人研究修改表结构会不会复制一张临时表,就看"rows affected “的值。如果为0,则表示不会拷贝中间表的方式,这样子就很快的。我没试过 使用专门的辅助工具。一些公司开发了自己的内部工具来辅助进行。比如facebook。 另外腾讯的技术也介绍了他们自己定制的tMySQL进行在线加字段的实现原理: http://www.zhdba.com/MySQLops/2013/09/14/MySQL-innodb-online-ddl/ facebook自己开发的工具,官网: http://bazaar.launchpad.net/~MySQLatfacebook/MySQLatfacebook/tools/files/head:/osc 我记得好像最先是facebook进行了方案创新(呵呵,当你的遇到的是复杂问题,没有人解决过就只能先创造新的技术方案了),当时冯大辉专门写了一篇,其他文章介绍他们的创新。其他工具都是跟这个思路差不多的。不过我下载了facebook官网的,是用php实现的。没具体看。因为下载的包里面都是php文件。 总的来说,这些工具大致的理大同小异: 表结构的修改在创建的一张新表中执行(这样不需要锁定原表了,也就不会影响MySQL提供服务),更为关键的是解决了一个问题,当这个间隔时间内,用户在使用MySQL,对表数据进行了更新怎么办？ 工具的解决办法思路是,在原表中创建几个触发器针对uptate、delete 、insert操作都记录下来,这样子把对原表的操作记录下来,方便更新到新建立的临时表中中去。 听过豆瓣网的架构变迁分享会中提到,他们以前在这方面也吃过苦头的,一张很大的表(比如上千万),在线加个索引,由于数据量大,整个应用就卡死了。 其实有时候卡几个小时可能都很正常。死锁了嘛。另外对临时表要进行复制数据,建立这个临时表也需要时间嘛。 他们现在用的办法是: 先拷贝一张一模一样的表,数量也是差不多,先在这张表上面测试,看看需要多长时间。如果几分钟,是在可以接受的时间范围内,就可以。如果几个小时就不行了。这样子提早预先知道。 另外,也使用了online-schema-change这个工具。 关于online-schema-change 是percona推出的一个针对MySQL在线ddl的工具 percona是一个MySQL分支维护公司,专门提供MySQL技术服务的。我的理解,类似于linux的分支redhat公司 官网下载地址为: http://www.percona.com/redir/downloads/percona-toolkit/2.2.1/percona-toolkit-2.2.1.tar.gz 腾讯,淘宝,百度这些公司多少都有自己开发的工具来解决这个头痛的问题。 另外,MySQL5.5企业版是支持在线ddl了,不过企业版要收费嘛 MySQL 5.6改进了安全功能,例如对关键配置文件和用户密码的加密方式,但是对InnoDB的提升才是大新闻。使用该存储引擎的最后一个主要障碍便是缺少全文索引,但是现在这个问题已经不复存在了。 该版本还为InnoDB引入了在线DDL,DBA一定会非常喜欢这个功能。增加、重命名和删除列等常用的操作可以和并发查询同时执行。尽管可能涉及到一些数据的复制或重组,但是大多数在线DDL操作都能够就地执行。

java import cert keytool -importcert -keystore /path/to/jre/lib/security/cacerts -storepass changeit -noprompt -file /path/to/ca.der -alias "digicertglobalrootca" # storepass 默认值changeit keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit | grep digicertglobalrootca

Git HEAD 当你提交（commit）新更改时，HEAD 会随着分支一起移动到新的提交。 当你切换分支（比如用 git checkout 或 git switch），HEAD 会改变指向，指向你切换到的分支。 这个 HEAD 随你切换分支而变化，始终指向你“当前所在”的分支或 commit。 你在 main 分支，HEAD 内容是 ref: refs/heads/main 你切换到 dev 分支，HEAD 变为 ref: refs/heads/dev 你 checkout 某个历史 commit，HEAD 内容是该 commit 的 SHA（分离 HEAD 状态） # 正常情况下(attached HEAD)，HEAD 是一个符号引用，指向当前分支 # 本地 HEAD 通常指向分支，而不是直接指向提交 cat .git/HEAD # 输出：ref: refs/heads/main # 1. HEAD 指向 main 分支 # 2. main 分支指向它的最新提交 # 3. HEAD 通过分支间接指向最新提交 # HEAD -> 分支 -> 最新提交 # HEAD → refs/heads/main → commit_abc123 # 查看 HEAD 指向的分支 git symbolic-ref HEAD # 输出：refs/heads/main # 查看 HEAD 最终指向的提交 git rev-parse HEAD # 输出：abc123...（提交SHA） git rev-parse HEAD # 获取当前HEAD指向的提交SHA git rev-parse main # 获取main分支的最新提交SHA cat .git/refs/heads/main # 直接查看分支文件内容（提交SHA） detached HEAD # 当检出具体 commit 时，HEAD 直接指向提交 git switch --detach commit_abc123 cat .git/HEAD # 输出：commit_abc123...（直接是提交SHA，不是 ref: 开头） # 此时 HEAD 直接指向提交，不通过分支 HEAD 的作用是告诉 Git “我现在在哪里工作” ...

单播、多播 (组播) 和广播 https://blog.csdn.net/wangerge/article/details/3931491 单播、多播和广播单播" (Unicast) 、“多播” (Multicast) 和"广播" (Broadcast) 这三个术语都是用来描述网络节点之间通讯方式的术语。那么这些术语究竟是什么意思？区别何在？ 1.单播: 网络节点之间的通信就好像是人们之间的对话一样。如果一个人对另外一个人说话,那么用网络技术的术语来描述就是"单播",此时信息的接收和传递只在两个节点之间进行。单播在网络中得到了广泛的应用,网络上绝大部分的数据都是以单播的形式传输的,只是一般网络用户不知道而已。例如,你在收发电子邮件、浏览网页时,必须与邮件服务器、Web服务器建立连接,此时使用的就是单播数据传输方式。但是通常使用"点对点通信" (Point to Point) 代替"单播",因为"单播"一般与"多播"和"广播"相对应使用。 2.多播: “多播"也可以称为"组播”,在网络技术的应用并不是很多,网上视频会议、网上视频点播特别适合采用多播方式。因为如果采用单播方式,逐个节点传输,有多少个目标节点,就会有多少次传送过程,这种方式显然效率极低,是不可取的；如果采用不区分目标、全部发送的广播方式,虽然一次可以传送完数据,但是显然达不到区分特定数据接收对象的目的。采用多播方式,既可以实现一次传送所有目标节点的数据,也可以达到只对特定对象传送数据的目的。 IP网络的多播一般通过多播IP地址来实现。多播IP地址就是D类IP地址,即224.0.0.0至239.255.255.255之间的IP地址。Windows 2000中的DHCP管理器支持多播IP地址的自动分配。 3.广播: “广播"在网络中的应用较多,如客户机通过DHCP自动获得IP地址的过程就是通过广播来实现的。但是同单播和多播相比,广播几乎占用了子网内网络的所有带宽。拿开会打一个比方吧,在会场上只能有一个人发言,想象一下如果所有的人同时都用麦克风发言,那会场上就会乱成一锅粥。集线器由于其工作原理决定了不可能过滤广播风暴,一般的交换机也没有这一功能,不过现在有的网络交换机也有过滤广播风暴功能了,路由器本身就有隔离广播风暴的作用。 广播风暴不能完全杜绝,但是只能在同一子网内传播,就好像喇叭的声音只能在同一会场内传播一样,因此在由几百台甚至上千台电脑构成的大中型局域网中,一般进行子网划分,就像将一个大厅用墙壁隔离成许多小厅一样,以达到隔离广播风暴的目的。 在IP网络中,广播地址用IP地址"255.255.255.255"来表示,这个IP地址代表同一子网内所有的IP地址。 当前的网络中有三种通讯模式: 单播、广播、组播(多播),其中的组播出现时间最晚但同时具备单播和广播的优点,最具有发展前景。 一、单播: 主机之间"一对一"的通讯模式,网络中的交换机和路由器对数据只进行转发不进行复制。如果10个客户机需要相同的数据,则服务器需要逐一传送,重复10次相同的工作。但由于其能够针对每个客户的及时响应,所以现在的网页浏览全部都是采用IP单播协议。网络中的路由器和交换机根据其目标地址选择传输路径,将IP单播数据传送到其指定的目的地。 单播的优点: 服务器及时响应客户机的请求 服务器针对每个客户不通的请求发送不通的数据,容易实现个性化服务。 单播的缺点: 服务器针对每个客户机发送数据流,服务器流量＝客户机数量×客户机流量；在客户数量大、每个客户机流量大的流媒体应用中服务器不堪重负。 现有的网络带宽是金字塔结构,城际省际主干带宽仅仅相当于其所有用户带宽之和的5％。如果全部使用单播协议,将造成网络主干不堪重负。现在的P2P应用就已经使主干经常阻塞,只要有5％的客户在全速使用网络,其他人就不要玩了。而将主干扩展20倍几乎是不可能。 二、 广播: 主机之间"一对所有"的通讯模式,网络对其中每一台主机发出的信号都进行无条件复制并转发,所有主机都可以接收到所有信息 (不管你是否需要) ,由于其不用路径选择,所以其网络成本可以很低廉。有线电视网就是典型的广播型网络,我们的电视机实际上是接受到所有频道的信号,但只将一个频道的信号还原成画面。在数据网络中也允许广播的存在,但其被限制在二层交换机的局域网范围内,禁止广播数据穿过路由器,防止广播数据影响大面积的主机。 广播的优点: 网络设备简单,维护简单,布网成本低廉 由于服务器不用向每个客户机单独发送数据,所以服务器流量负载极低。 广播的缺点: 1.无法针对每个客户的要求和时间及时提供个性化服务。 网络允许服务器提供数据的带宽有限,客户端的最大带宽＝服务总带宽。例如有线电视的客户端的线路支持100个频道 (如果采用数字压缩技术,理论上可以提供500个频道) ,即使服务商有更大的财力配置更多的发送设备、改成光纤主干,也无法超过此极限。也就是说无法向众多客户提供更多样化、更加个性化的服务。 广播禁止在Internet宽带网上传输。 三、组播: 主机之间"一对一组"的通讯模式,也就是加入了同一个组的主机可以接受到此组内的所有数据,网络中的交换机和路由器只向有需求者复制并转发其所需数据。主机可以向路由器请求加入或退出某个组,网络中的路由器和交换机有选择的复制并传输数据,即只将组内数据传输给那些加入组的主机。这样既能一次将数据传输给多个有需要 (加入组) 的主机,又能保证不影响其他不需要 (未加入组) 的主机的其他通讯。 组播的优点: 需要相同数据流的客户端加入相同的组共享一条数据流,节省了服务器的负载。具备广播所具备的优点。 由于组播协议是根据接受者的需要对数据流进行复制转发,所以服务端的服务总带宽不受客户接入端带宽的限制。IP协议允许有2亿6千多万个 (268435456) 组播,所以其提供的服务可以非常丰富。 此协议和单播协议一样允许在Internet宽带网上传输。 组播的缺点: 1．与单播协议相比没有纠错机制,发生丢包错包后难以弥补,但可以通过一定的容错机制和QOS加以弥补。 2．现行网络虽然都支持组播的传输,但在客户认证、QOS等方面还需要完善,这些缺点在理论上都有成熟的解决方案,只是需要逐步推广应用到现存网络当中。

linux Namespace https://lwn.net/Articles/531114/ https://coolshell.cn/articles/17010.html Linux Namespace是Linux提供的一种内核级别环境隔离的方法。 chroot内部的文件系统无法访问外部的内容。Linux Namespace在此基础上,提供了对UTS、IPC、mount、PID、network、User等的隔离机制。 UTS Namespace IPC全称 Inter-Process Communication, 是 Unix/Linux下进程间通信的一种方式, IPC 有共享内存、信号量、消息队列等方法。

JWT, JSON Web Token 会话 会话跟踪技术是一种在客户端与服务器间保持 HTTP 状态的解决方案,我们所熟知的有 Cookie + Session、URL 重写、Token 等。 jwt JWT 的全称是 Json Web Token,是一种基于 JSON 的、用于在网络上声明某种主张的令牌 (token) 规范。 JWT 由三部分组成: head、payload、signature, 各部分通过 . 连接 xxxx . yyyy . zzzz HEAD 头部是一个 JSON 对象,包含了一些元数据, 存储描述数据类型 (JWT) 和签名算法 (HS256(HMAC-SHA256) 、RS256(RSA-SHA256) 还有 ES256(ECDSA-SHA256)) ,通过 Base64UrlEncode 编码后生成 head 。 { "typ" : "JWT", "alg" : "HS256" } type: 必需。token 类型,JWT表示是 JSON Web Token. alg: 必需。token 所使用的签名算法, 可用的值在这里有规定。 PAYLOAD 负载存放一些传输的有效声明,可以使用官方提供的声明, 也可以自定义声明。同样通过 Base64UrlEncode 编码后生成 payload。 声明可以分为三种类型: ...

SPA 单页应用程序 单页Web应用 (single page web application,SPA) ,就是只有一张Web页面的应用,是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。单页Web应用 (single page web application,SPA) ,就是只有一张Web页面的应用。单页应用程序 (SPA) 是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。 [1] 浏览器一开始会加载必需的HTML、CSS和JavaScript,所有的操作都在这张页面上完成,都由JavaScript来控制。因此,对单页应用来说模块化的开发和设计显得相当重要。

日期格式标准 如时间为: 2020-01-12T15:17:21 国际标准化组织的国际标准ISO 8601是日期和时间的表示方法，全称为《数据存储和交换形式·信息交换·日期和时间的表示方法》 原文如下： 日期和时间的组合表示法编辑 合并表示时，要在时间前面加一大写字母T，如要表示北京时间2004年5月3日下午5点30分8秒，可以写成2004-05-03T17:30:08+08:00或20040503T173008+08。 所以这个T date和time合并表示时，中间加个T。 iso 8806的百度地址是： https://baike.baidu.com/item/ISO%208601/3910715?fr=aladdin ———————————————— 版权声明：本文为CSDN博主「chushiyunen」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/enthan809882/article/details/103946177 https://www.cnblogs.com/tzyy/p/5099207.html ISO日期格式标准,浏览器到服务器到MySQL中的时区 章节目录 时区简单理解 ISO_8601 日期格式标准 HTML5 input 标签datetime属性 MySQL时区 时区简单理解 https://zh.wikipedia.org/wiki/%E6%97%B6%E5%8C%BA 上面的链接是时区的wiki说明,下面说说我记住的部分: GMT时区是格林威治标准时间,我把它理解为 “真实时间” UTC时区是根据GMT得来的"世界标准时间",它的时间和GMT是相同的 CST可以指下列的时区: 澳洲中部时间,Central Standard Time (Australia) 中部标准时区 (北美洲) ,Central Standard Time (North America) 北京时间,China Standard Time 古巴标准时间,Cuba Standard Time,参见北美东部时区 其中我们所在的时区背景时间 CST=UTC+8小时,也就是说,真实时间是0点的时候,背景时间是8点 ISO_8601日期格式标准 https://zh.wikipedia.org/wiki/ISO_8601 上面是日期格式标准的wiki 当前的UTC时间是2016-01-07T01:58Z, 其中Z是4位数字格式的时间偏移量, 不写的时候默认不偏移。 其中,字母T代表使用UTC时间,字母Z代表时间偏移量,实际写法中字母Z应该被偏移量替换,例如 “2017-1-7T10:21+0800"或者"2017-1-7T10:21-0800”,字母Z被+0800和-0800替换了。 在浏览器中直接new一个date对象,因为我们处于UTC+0800的时区,所以控制台给我们打印出来的时间是GMT+0800的时间 2016-01-07T00:00 代表UTC时区1月7日0时0分 (在控制台中显示UTC+0800时区为8时0分) 2016-01-07T00:00 0800 代表UTC+0800时区1月7日0时0分,2016-01-07T00:00 -0800 代表UTC-0800时区1月7日0时0分,在控制台中显示分别如下 ...

docker mirror 登录容器Hub服务的控制台,左侧的加速器帮助页面就会显示为你独立分配的加速地址。 https://yq.aliyun.com/articles/29941 https://www.docker-cn.com/registry-mirror 永久性保留更改,您可以修改 /etc/docker/daemon.json 文件并添加上 registry-mirrors 键值。 vim /etc/docker/daemon.json #(create it if it does not exist) { "registry-mirrors": ["https://registry.docker-cn.com"], "insecure-registries": [ "registry.wiloon.com" ] } ### restart docker service # 修改保存后重启 Docker 以使配置生效。 sudo systemctl daemon-reload sudo systemctl restart docker.service ### 查看 sudo docker info daemon.json { "registry-mirrors": ["https://registry.docker-cn.com", "http://hub-mirror.c.163.com","https://docker.mirrors.ustc.edu.cn"] } http: server gave HTTP response to HTTPS client https://stackoverflow.com/questions/49674004/docker-repository-server-gave-http-response-to-https-client { "insecure-registries":["192.168.99.100:5000"] }

linux string cut, sort https://www.cnblogs.com/farwish/p/4806018.html https://blog.csdn.net/xwhself/article/details/6118722

elk install download elasticsearch https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.3.1.rpm install jdk8 yum localinstall elasticsearch-6.3.1.rpm start elasticsearch, it will generate default config file systemctl start elasticsearch edit config file /etc/elasticsearch/elasticsearch.yml path.data: /data/server/elasticsearch path.logs: /data/server/elasticsearch network.host: 0.0.0.0 mkdir -p /data/server/elasticsearch/ chown -R elasticsearch:elasticsearch elasticsearch/ systemctl restart elasticsearch install ingest geoip plugin download from https://artifacts.elastic.co/downloads/elasticsearch-plugins/ingest-geoip/ingest-geoip-6.3.1.zip download kibana yum localinstall kibana edit kibana config file, vi /etc/kibana/kibana.conf server.host: “xxx” elasticsearch.url: “http://elasticsearch-ip:9200” systemctl restart kibana check if kibana works http://kibana-ip:5601 download and install filebeat