Composer入门

1. 新建目录composer_test 后续的所有操作都在该目录下执行。所以现在该目录为空。 2. 使用Composer下载第一个包(monolog/monolog) 方法一 在当前目录下直接执行require命令: composer require monolog/monolog 。 该命令首先会在目录下寻找composer.json文件,如果没有的话则自动创建composer.json并将require的依赖包写入该文件。 然后再去composer源上下载所需要的依赖包,放到vendor目录下。 将依赖包的顶级命名空间与其源码目录的对应关系写入到/vendor/composer目录下的autoload_*文件中。 运行完命令后目录结构变成如下图所示。 /composer.json文件 是composer进行项目依赖管理的配置文件。 /composer.lock文件 是composer下载依赖包时候创建的文件,它记录了当前下载到的所有依赖包的版本。 /vendor目录 […]

snmpd配置

最近在看snmp相关的知识,在centos上安装的snmpd进行测试。 执行如下三条指令 # 查看所有OID snmpwalk -v 2c -c public localhost # 查看系统基本信息 snmpwalk -v 2c -c public localhost .1.3.6.1.2.1.1.1.0 #

bbr还是要开的

之前试验过开bbr,但是可能以前的网络环境没那么糟糕,所以没有特别明显的差距。 今年由于新型冠状病毒肺炎(COVID-19)疫情,墙又开始大封锁。我把之前的gcp关掉重新开了一台,然后这台是没有开启过bbr的。今天ping值<15ms,无丢包的情况下,看youtube的480p都卡。然后尝试更新了linux内核,打开bbr。结果youtube 1080p丝般顺滑。。。震惊了!居然这么屌的嘛。 检查是否已开启 bbr (a)  执行如下命令,检查 bbr 是否可用: sudo sysctl net.ipv4.tcp_available_congestion_control 应该输出类似下面这样的信息(包括bbr,顺序无所谓): net.ipv4.tcp_available_congestion_control = bbr cubic reno (b) 执行如下命令:

PostgreSQL数据库复制

这篇博客的行文可能有点“官方”,因为是之前为了发期刊而写的初稿。 postgersql是一款功能强大的开源数据库系统。它基于并扩展了SQL语言,使之支持更复杂的数据类型。它提供了丰富的接口,可以很容易地扩展它的功能,比如最知名的地理空间数据库扩展PostGIS。PostgreSQL以其稳定性、可扩展性以及软件背后开源社区的奉献精神而赢得了良好的声誉,并得到了广泛的应用。 数据库复制是指在多个数据库节点之间完整一致地共享数据的过程。不论其具体使用场景如何,数据库复制的目的都是为了实现数据库的高可用性与负载均衡。高可用性是指当主节点失效的时候,备用节点能快速接手工作;负载均衡是指将工作分流给多个节点,以平衡每个节点的压力。 我们希望多个数据库节点可以无缝地协同工作,但是实际上,只有用做只读服务器的节点能够相对容易的结合在一起。大部分情况下,数据库收到的请求都是读写混合的,对于任意节点的一次写入动作必须实时的传播给其他节点,这样才能保证后续对任意节点的读取请求能够返回一致的结果。如何保证多个节点的数据一致性是数据库复制技术的难题,也是数据库协同工作的核心。PostgreSQL支持多种实现数据库复制的技术方案,每种方案都各有其优缺点,都是为了满足特定环境下的特定需求。 有的方案只允许在一个节点上进行写操作,这个可写的节点称为主节点(主服务器)。其他从主节点复制数据的则称为从节点(从服务器)。另外,从节点又根据其是否可读分为温备与热备。温备是指从节点只有当被提升为主节点的时候才允许用户连接进行读写操作,热备是指从节点任何时候都可以处理读取请求。除了主从复制方案,有时候我们会需要双向复制方案,来实现任意节点都可读写的需求。 有的方案是同步复制的,即一个数据修改事务只有到所有节点均提交了该事务后才能被认为是提交成功的。相反有些方案是异步的,即允许事务在某个节点上的提交与它被传播到其他节点之间存在延迟。异步复制会导致在某些时刻两个节点的数据不一致,但是它对于网络延迟的要求比同步复制宽容的多。 有的方案只能对整个数据库节点进行复制,有的则允许细分到每个库,甚至每张表的复制。 1 流复制 1.1 预写式日志(WAL) 预写式日志(WAL, Write Ahead Log)是PostgreSQL内置复制技术的基石,其作用与Oracle数据库的重做日志类似,都是用于保证数据的一致性以及事务的完整性。WAL的核心概念是数据文件的修改必须在这些动作被日志记录之后才被写入[1]。只要有了数据库的一个早期基础备份,以及后续的WAL文件,那么不论是在系统崩溃需要恢复的时候,还是在另一台机器重建数据库的时候,都可以很容易的通过重放WAL中的日志项来还原数据库,达到WAL记录中任意时间点的状态。我们将这种恢复数据库的方案叫做时间点恢复(PITR, Point In Time Recovery),这也是PostgreSQL流复制与逻辑复制的基本原理。 WAL文件被存储在数据库目录的pg_wal子目录下,默认大小为16MB。可以通过postgresql.conf配置文件中的wal_level配置项来决定有多少日志信息输出到WAL中。wal_level分为三个等级,minimal表示只输出最基本的日志信息,以供系统崩溃或异常停机时候恢复数据所用;replica表示输出足够的日志信息以支持WAL归档和复制,这是WAL的默认等级;logical表示增加支持逻辑解码所需的信息,这是PostgreSQL内置的逻辑复制需要的等级。

postgresql的timestamp类型与python的datetime类型之间的坑

最近的项目突然发现一个bug,就是当服务器系统时区是utc时区,而服务器pgsql的时区是+8时区时候,通过python的datetime.now()插入的timestampz值有问题。所以特意做了一个测试。 1 测试前提 1.1 python的datetime类型 首先,要了解python的datetime类型是包括时间与时区的。而通过datetime.now()与datetime.utcnow()获得的时间其tzinfo属性为null,即不带时区属性。要想获得带时区属性的datetime类型,就必须使用datetime.now(tz=timezone.utc)或者datetime.now(tz=timezone(timedelta(hours=8)))。 1.2 pgsql的时间戳类型 然后,pgsql的时间戳类型包括timestamp(无时区), timestampz(有时区)两种。 1.3 测试表与测试代码 为了进行测试,我新建了一张time_test表,然后分别插入pythono的datetime.now(), datetime.utcnow(), datetime.now(timezone.utc)三个值。 #!/usr/bin/env python # -*- coding:

midi文件解析 by python mido

首先要记住,midi文件并不存储声音,只存储指示合成器(电子乐器)如何发声的动作,比如某个时刻以什么力度按下某个音符。 音符note 狭义的音符指C、D、E、F、G、A、B七个(即Do–Re–Mi–Fa–Sol–La–Si)。广义的应该是包括音符与对应的音阶,比如中央C即C4。音符、琴键与它们在midi中编号的关系如下图所示: 在midi信息中的note number从[21, 108]对应着钢琴的88个琴键。 midi channels 通道,最多有16个通道。可以了解为每个通道对应一个物理输出,所以midi最多可以同时控制16种乐器。 midi tracks 音轨,音轨与通道并不是一一对应,而是可以多对多的关系。音轨是逻辑上的划分,比如可以将钢琴的左手演奏放在track 1,右手演奏放在track 2。但是输出时候,都是对应输出到钢琴的通道。你也可以只设置一个track 1,并且在里面记录着不同通道的消息。另外,还经常将track 0用来存储midi的元信息。 event 事件,也叫做消息(在mido库中使用message表示)。包括三种事件meta event,midi event,

raspberry pi

1、摄像头相关 1.1 拍照 raspistill -o image.jpg 1.2 录影 raspivid -o video.h264 默认录制5秒钟的视频, 1.3 视频串流到vlc raspivid -o – -t 0 -vf

postgresql的pg_hba.conf

初识postgresql的时候,觉得它的连接认证真几把烦人。每次也都是直接在网上搜索复制,不求甚解。今天安装bucardo做双主复制的时候,又被这个连接认证搞的头疼。索性好好试验了一方,才发现网上根本就没人好好说过ident连接方式失败的原因,全是复制文。。。哎。 先贴上官方文档:https://www.postgresql.org/docs/10/auth-pg-hba-conf.html 在实际使用时候,通常只会用到下面这种格式: # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all

使用pgbench对PostgreSQL进行压力测试

1、安装pgbench yum install postgresql10-contrib   2、初始化pgbench使用的库 首先将shell切换到postgres用户下,使用psql新建一个测试用的数据库pgbench。 postgres=# CREATE DATABASE pgbench; CREATE DATABASE postgres=# \q 然后执行如下命令初始化pgbench库 # pgbench -i [option…]

Scroll to Top