Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.
1 | $ hexo new "My New Post" |
More info: Writing
1 | $ hexo server |
More info: Server
1 | $ hexo generate |
More info: Generating
1 | $ hexo deploy |
More info: Deployment
The issue is with Wayland. While Ubuntu defaults to an X11 session, for some reason they left it enabled for GDM.
Ubuntu18.04重启之后会出现无法连接网络的问题，排查得问题出现在DNS上，然而中文社区对这个方法的解决都不甚令人满意，折腾了半个晚上，才发现This is pretty simple to fix though.
添加用户
useradd -d /home/test test -m，创建用户test(自动生成目录)，该用户属于test用户组
useradd -d /home/a a -g test -m，创建用户a，属于test用户组
-d：指定用户登录系统时的主目录
-m：自动建立目录
-g：指定组名称
设置密码
passwd test
删除用户
userdel test删除test用户，但并不删除/home/test
userdel -r test删除test用户与其目录
切换用户
su
查看当前用户组
cat /etc/groupgroupmod+三次tab键组账号操作
groupaddgroupdelcat /etc/groupusermod -g group_name user_name查看用户组成员
groups group_name
为新用户添加sudo权限
sudo usermod -a -G adm user_name
sudo usermod -a -G sudo user_name
实例：
linux环境下创建新用户在使用docker中会遇到permission denied的问题，这是由于docker启动守护进程的时候，会默认赋予docker用户组的成员读写unix socket的权限，因此，将新用户加入到docker用户组中，问题就可以解决了：
sudo usermod -a -G docker zjs
之后需要更新用户组newgrp docker
修改文件权限
字母法：chmod u/g/o/a +/-/= rwx file_name
| 所有者 | 含义 |
|---|---|
| u | user |
| g | group |
| o | other |
| a | all |
| + - = | 含义 |
|---|---|
| + | 增加权限 |
| - | 撤销权限 |
| = | 设定权限 |
| r w x | 含义 |
|---|---|
| r | read |
| w | write |
| x | excute |
数字法：
chomod 777 test/ -R -R表示级联授权
777：所有者用户/组内其他用户/其他组用户 = rwx/rwx/rwx
修改文件所有者
chown user_name file_name
修改文件所属组
chgrp group_name file_name
添加用户赋予权限：
sudo vi /etc/sudoersroot ALL=(ALL) ALL下添加一行test ALL=(ALL) ALLlinux在启动过程中通过读取/etc/profile文件中内容完成相关环境的载入，而ssh登陆远程主机的时候并不会加载/etc/profile中的配置文件。
因此jdk安装完成后需要两次配置，一为配置/etc/profile中的环境变量，二将hadoop启动脚本中调用的HADOOP_HOME改为绝对路径的形式。
本文将介绍类Unix系统中一系列文件目录存放的基本原则与标准。这篇向导旨在为系统的交互性、系统的管理工具、开发工具、脚本提供支持，使其在所有系统中更加统一。本文参考
Firewalld is installed on CentOS 7 as default. Here comes some operations of it.
sudo firewall-cmd --statesudo systemctl disable firewalld(禁止开机启动)sudo systemctl stop firewalldsudo ufw statussudo ufw status verbosesudo ufw enablesudo ufw disable基操：
sudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw allow ssh or sudo ufw allow 22sudo ufw allow 2222sudo ufw allow http or sudo ufw allow 80sudo ufw allow https or sudo ufw allow 443sudo ufw allow 6000:6003/tcpsudo ufw allow 6000:6003/udp习惯了Hyper+WSL+zsh的组合，在centos中也得安排上，备查。
事务是并发控制地基本单位，为了保证事务地隔离性和一致性，DBMS需要对并发操作进行正确的调度。
并发操作带来的数据不一致性包括丢失数据、不可重复读、读脏数据。
丢失数据lost update：两个事务读入同一数据并修改，一个提交的结果破坏了另一个提交的结果，导致修改被丢失。
不可重复读non-repeatable read：指事务T1读取数据后，事务T2执行更新操作，使T无法再现前一次读取结果。具体分三种：
后两种不可重复读有时也被称为幻影(phamtom row)现象。
读脏数据dirty read：T1修改某一数据并写回磁盘，T2读该数据，T1 rollback，T2读到的数据与数据库中的数据不一致。
并发控制的主要技术：封锁(locking)，时间戳(timestamp)，乐观控制法(optimistic scheduler)，多版本并发控制(multi-version concurrency control,MVCC)
事务对某个数据进行加锁，在其释放前，其他食物不能更新此数据对象。
基本的封锁类型有两种：
封锁协议：规定合适申请X锁或S锁、持锁时间、何时释放等。
一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括COMMIT, ROLLBACK。
一级封锁协议中，如果仅仅是读数据而不是对其进行修改，是不需要加锁的，所以它**不能保证 可重复读 和 不读脏数据。
二级封锁协议：在一级封锁协议的基础上，增加事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。
由于读完即可释放S锁，所以他不能保证 可重复读。
三级封锁协议：在一级封锁协议的基础上增加 事务T在读取数据R之前必须先对其加S锁，直到该事务结束之后才释放。
可解决不可重复读、读脏数据问题。
三级协议的主要区别在于什么操作需要申请封锁，以及合适释放锁。
活锁 ：T1封锁数据R，T2请求封锁R，后T3也请求封锁R，T1释放R后首先批准了T3的请求，也就是说T2被插队了，如果T2一直被插队，那么称之为活锁。
解决方法：先来先服务。
死锁 ：循环等待。
死锁的预防：
一次封锁法：要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。
缺陷：1.扩大封锁范围，降低并发度；2.很难事先确定需要封锁的数据对象。
顺序封锁法：预先对数据对象规定一个封锁顺序，所有事务都按照这个顺序实施封锁。
缺陷：1.数据库系统中封锁的数据对象极多，并且不断变化，要维护这样的资源的封锁顺序非常困难，成本很高；2.很难事先确定要封锁那些对象，一次也就很难按规定的顺序去施加封锁。
死锁的诊断与解除 ：
解除死锁：选择一个处理死锁代价最小的事务，将其撤销，释放此事务持有地所有锁。
可串行化调度：多个事务地并发执行是正确的，当且仅当其结果与按某一次序串行执行这些事务地结果相同时，称这种调度策略为可串行化serializable的。
可串行性是并发实物正确调度的准则。
冲突操作是指不同事务对同一数据的读写操作和写写操作。而其他操作是不冲突操作。
通过交换两个事务不冲突操作的次序得到另一个调度Sc‘，如果Sc’是串行的，则称调度Sc为冲突可串行化的调度。因此可以用这种方法来判断一个调度是否是冲突可串行化的。
冲突可串行化调度是可串行化调度的充分条件，不是必要条件。
所谓2PL协议是指所有事务必须分两个阶段对数据项加锁和解锁：
事务分为两个阶段，第一阶段是获得封锁，也成为扩展阶段，此阶段可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁；第二阶段是释放封锁，也称为收缩阶段，该阶段事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁。
若并发执行的所有事务均遵循两段锁协议，则对这些事务的任何并发调度都是可串行化的。
严格两段锁协议：除要求满足两段锁协议规定外，还要求事务的排它锁必须在事务提交之后释放
强两段锁协议：除要求满足两段锁协议规定外，还要求事务的所有锁都必须在事务提交之后释放
事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件。
封锁对象的大小称为封锁的粒度，封锁粒度与系统的并发度和并发控制的开销密切相关。
封锁的粒度越大，数据库所能封锁的单元就越少，并发度越小，系统开销越小。
多粒度封锁：一个系统中同时支持多种封锁粒度供不同的事务选择。
引入多粒度树的概念，三级粒度树(数据库，关系，元组)，四级粒度树(数据库，数据分区，数据文件，数据记录)。多粒度封锁协议允许多粒度树中的每个结点被独立的加锁。对一个结点加锁意味着这个结点的所有后裔结点也被加以同样类型的锁。
显式封锁：应事务要求直接加到数据对象上的锁。
隐式封锁：该数据对象没有被独立加锁，而是由于其上级结点加锁而使该数据对象加上了锁。
一般地，对于某个数据对象加锁，系统要检查该数据对象上有无显式封锁与之冲突，还要检查上级结点传下来的隐式封锁是否冲突，以及传给下级结点的封锁是否冲突，这样的检查方法效率很低，因此引入意向锁。
意向锁：如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的上层结点加意向锁。
三种常用的意向锁，意向共享锁(Intent Share Lock，IS锁)，意向排他锁(Intent Exclusive Lock, IX锁)，意向共享排他锁(Share Intent Exclusive Lock, SIX锁)
IS锁：如果对一个数据对象加IS锁，表示它的后裔结点拟加S锁。
例如，事务T1要对R1中某个元组加S锁，则要首先对关系R1和数据库加IS锁
IX锁：如果对一个数据对象加IX锁，表示它的后裔结点拟加X锁。
SIX锁：如果对一个对象加SIX锁，表示对它加S锁，再加IX锁，即SIX=S+IX。
课后题：
正确的调度->可串行化的调度->遵守两阶段封锁的调度->串行调度
在讨论数据库恢复计数之前先要明确事务的基本概念和事务的性质。
事务：用户定义的一个数据库操作序列，这些操作要么全做要么全不做，是一个不可分割的工作单位。在SQL中，定义事务的语句有3条：
BEGIN TRANSACTION
COMMIT
ROLLBACK
特性：ACID——原子性Atomisticy、一致性Consistency、隔离性Isolation、持续性Durability。
事务内部的故障：事务没有打到预期的终点(COMMIT或者显示的ROLLBACK)，因此，数据可可能出于不正确的状态。事务内部更多的故障是非预期的，是不能由应用程序处理的。
系统故障：系统故障是指造成系统停止运转的任何时间，是的系统要重新启动。如：CPU故障、操作系统故障、DBMS代码错误、系统断电等。发生系统故障时，一些尚未完成的事务结果可能已送入物理数据库，从而造成数据库可能出于不正确的状态。
恢复子系统必须在系统重新启动时让所有非正常中值的事务回滚，还需要重做REDO所有已提交的事务，以将数据库真正恢复到一致状态。
介质故障：系统故障常被成为软故障(soft crash) ，介质故障成为硬故障(hard crash) 。硬故障指外存故障，如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。发生几率小，但破坏性巨大。
计算机病毒
恢复的基本原理：冗余。也就是说数据库中任何一部分被破坏或不正确的数据可与根据存储在系统别处的冗余数据来重建。
恢复机制关键问题：如何建立冗余数据，如何利用这些冗余数据实施数据库恢复。
建立冗余数据最常用的技术时数据转储和登记日志文件logging(通常二法并用)。
转储即数据库管理员定期地将整个数据库复制到磁盘、磁带或其他存储介质上保存起来的过程。这些备用数据成为后备副本backup。转储是十分耗费时间和资源的，不能频繁进行，应根据数据库使用情况确定一个适当的转储周期。
静态转储：系统中午运行事务时进行的转储操作。 即转储操作开始的时刻，数据库出游一致性状态，而转储期间不允许对数据库的任何存取、修改活动。缺点：降低数据库的可用性。
动态转储：转储期间允许对数据库进行存取或修改。缺点：转储结束时backup上的数据并不能保证正确有效，可能已经是过时的数据了。
解决方法：将转储期间各事务对数据库的修改活动登记下来，建立日志文件log file。
转储还分为海量转储和增量转储两种方式。
日志文件的格式和内容
日志文件：用来记录事务对数据库的更新操作的文件。分为已记录为单位的日志文件和以数据块为单位的日志文件。
日志文件中需要登记的内容：
日志文件的作用：
为保证数据库是可恢复的，登记日志文件时必须遵循两条原则：
事务故障的恢复 ：事务在运行至正常终止点前被终止，恢复子系统应利用日志文件撤销UNDO此事务一堆数据库进行的修改。由系统自动完成 ，对用户是透明的，步骤为：
系统故障的恢复 ，成因有两个：1.未完成事务对数据库的更新已写入数据库；2.已提交事务对数据库的更新还留在缓冲区。该恢复由系统在重新启动时自动完成，不需要用户干预。
恢复步骤：
BEGIN TRANSACTION 和 COMMIT)，标记记入重做队列(REDO LIST)，同时找出故障发生时尚未完成的事务(只有BEGIN TRANSACTION无COMMIT)，标记记入撤销队列(UNDO LIST)介质故障的恢复 ，恢复方法：重装数据库，重做已完成的事务。(装入最新backup，装入相应的日志文件副本)
在日志文件中增加一个新的记录——检查点checkpoint记录，增加一个重新开始文件，并让恢复子系统在登录日志文件期间动态地维护日志。
checkpoints记录内容:
动态维护日志文件的方法是，周期性地执行建立检查点、保存数据库状态地操作。
使用检查点方法可以改善恢复效率。