CCIE那点事 http://www.rygqfb.tw IT运维故障发现和解决基地 我致力于为企业IT管理提供助力! Thu, 29 Aug 2019 05:24:03 +0000 zh-CN hourly 1 https://wordpress.org/?v=4.6.16 DDL/DML/DCL区别概述 http://www.rygqfb.tw/?p=4192 http://www.rygqfb.tw/?p=4192#respond Thu, 29 Aug 2019 05:24:03 +0000 http://www.rygqfb.tw/?p=4192 DDL

DDL的概述

DDL(Data Definition Language 数据定义语言)用于操作对象和对象的属性,这种对象包括数据库本身,以及数据库对象,像:表、视图等等,DDL对这些对象和属性的管理和定义具体表现在Create、Drop和Alter上。特别注意:DDL操作的“对象”的概念,”对象“包括对象及对象的属性,而且对象最小也比记录大个层次。以表举例:Create创建数据表,Alter可以更改该表的字段,Drop可以删除这个表,从这里我们可以看到,DDL所站的高度,他不会对具体的数据进行操作。

DDL的主要语句(操作)

Create语句:可以创建数据库和数据库的一些对象。

Drop语句:可以删除数据表、索引、触发程序、条件约束以及数据表的权限等。

Alter语句:修改数据表定义及属性。

DDL的操作对象(表)

表的概念

表的创建就是用?#21019;?#25918;数据用的,由于我们存放的数据的不通,所以我们需要定义些数据类型,以方便管理。

表的属性

主键属性:主键就是主键约束,只不过起的名字不同了,主键的起名偏向于虚的(就是描述描述这件事),主键约束起名偏向于实得(就是描述操作的实施),描述的都是同一件事,主键约束就是表中的一个属性;在一个表中最多可以有一个主键;一个主键可以定义在一个或多个字段;主键使一个或多个字段的值必须唯一且不为空,这样做可以通过该字段或该组字段中的值唯一的代表一条记录。

唯一属性:一个表中只能有一个主键属性,为了方表用户,提出唯一约束;唯一约束可以定义在一个或多个字段上;唯一约束使该字段或该组字段中的值唯一,可以为空,但是,不能重复。

外键属性:又?#22411;?#38190;,又?#22411;?#38190;约束,跟主键和主键约束的关系?#19988;?#26679;的;外键约束针对的两个表,如果表A的主关键字是表B中的字段,则该字段称为表B的外键,表A称为主表,表B称为从表,但要注意,必须要计算机要知道你是这种关系。

核查、Null和缺省属性:核查属性又叫核查约束,Null属性又叫Null约束,缺省属性又叫缺省约束;这些名称是描述一件事,描述一种情况,这件事或这张情况我们?#27604;?#21487;以人为的那样特意做(输入数据是注意就行),但是,他们的本意是实现自动化,也就是让计算机做这件事。

(你知道为什么建立主键和唯一约束的时候,会自动的创建索引吗?而且是唯一索引,想一想索引大多在那些字段上用,以及索引的作用就会知道了。像主键约束、唯一约束、非空约束、外键约束、核查约束和缺省约束这些操作都是使表具有某些特性,所以在这里我认为他们都是表的属性。)

DML

DML的概述

DML(Data Manipulation Language 数据操控语言)用于操作数据库对象中包含的数据,也就是说操作的单位是记录。

DML的主要语句(操作)

Insert语句:向数据表张插入一条记录。

Delete语句:删除数据表中的一条或多条记录,也可以删除数据表中的所有记录,但是,它的操作对象仍是记录。

Update语句:用于修改已存在表中的记录的内容。

DML的操作对象——记录

注意

当我们对记录进行Insert、Delete和Update操作的时候,一定要注意,一定要清楚DDL对其的一些操作。

DCL

DCL的概述

DCL(Data Control Language 数据控制语句)的操作是数据库对象的权限,这些操作的确定?#25925;?#25454;更加的安全。

DCL的主要语句(操作)

Grant语句:允许对象的创建者给某用户或某组或所有用户(PUBLIC)某些特定的权限。

Revoke语句:可以废除某用户或某组或所有用户访问权限

DCL的操作对象(用户)

此时的用户指的是数据库用户。

]]>
http://www.rygqfb.tw/?feed=rss2&p=4192 0
redis-cluster http://www.rygqfb.tw/?p=4190 http://www.rygqfb.tw/?p=4190#respond Mon, 19 Aug 2019 11:56:28 +0000 http://www.rygqfb.tw/?p=4190 一,为什么要用redis-cluster

1.并发问题
redis官方生成可以达到 10万/每秒,每秒执行10万条命令
假如业务需要每秒100万的命令执行呢?

2.数据量太大

一台服务器内存正常是16~256G,假如你的业务需要500G内存,你怎么办?解决方案如下

  1. 配置一个超级牛逼的计算机,超大内存,超强cpu,但是问题是。。。。

2.正确的应该是考虑分布式,加机器,把数据分到不同的位置,分摊集中式的压力

二,客户端?#21046;?/h4>
redis实例集群主要思想是将redis数据的key进行散列,通过hash函数特定的key会?#25104;?#21040;指定的redis节点上

数据分布

顺序分区

哈希分区(redis-cluster用的是哈希分区)

节点取余

 

计算示例 

节点  0 1 2

对1到6取余

1  1/3 =1  对应 节点1

2  2/3 =2 对应 节点2

3  3/3 =0  对应 节点0

4  4/3 =1

5  5/3 = 2

6  6/3 = 0

 

 

 

例如按照节点取余的方式,分三个节点

1~100的数据对3取余,可以分为三类

  • 余数为0
  • 余数为1
  • 余数为2

那么同样的分4个节点就是hash(key)%4

节点取余的优点是简单,客户端?#21046;?#30452;接是哈希+取余

一致性哈希

客户端进行?#21046;?#21704;希+顺时针取余

 

是个封闭 环

 

虚拟槽分区
每一个数据的键被哈希函数?#25104;?#21040;一个槽位,redis-cluster规定一共有16384个槽位

三,搭建集群

单机模式

分布式架构

分布式架构

多个服务端,负责?#21015;矗?#24444;此通?#29275;瑀edis指定了16384个槽,ruby的脚本自动就把分配槽位这事做了

]]>
http://www.rygqfb.tw/?feed=rss2&p=4190 0
mysql备份还原-基于binlog的增量备份还原 http://www.rygqfb.tw/?p=4188 http://www.rygqfb.tw/?p=4188#respond Mon, 19 Aug 2019 06:24:55 +0000 http://www.rygqfb.tw/?p=4188  

启用binlog

vi my.cnf

log-bin=/var/lib/mysql/mysql-bin.log,如果是这样的话log-bin=mysql-bin.log默认在datadir目录下面

[root@BlackGhost mysql]# ls |grep mysql-bin
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.000004
mysql-bin.000005
mysql-bin.000006
mysql-bin.index

 

查看mysql-bin.000002这样的文件里面到底是什么东西

[root@BlackGhost mysql]# mysqlbinlog   /var/lib/mysql/mysql-bin.000002 > /tmp/add.sql

binlog增量备份和增量还原

1,增量备份

既然我们知道了,mysql里面新增加的数据在mysql-bin这样的文件里面,我们只要把mysql-bin这样的文件进行备份就可以了。

cp /var/lib/mysql/mysql-bin* /data/mysql_newbak/

备份命令

mysqlbinlog --read-from-remote-server --raw --host=192.168.244.145 --port=3306 --user=repl --password=repl --stop-never  mysql-bin.000001

解释如下:

–read-from-remote-server:用于备份远程服务器的binlog。如果不指定该选项,则会查找本地的binlog。

–raw:binlog日志会以二进制格式存储在磁盘中,如果不指定该选项,则会以文本?#38382;?#20445;存。

–user:复制的MySQL用户,只需要授予REPLICATION SLAVE权限。

–stop-never:mysqlbinlog可以只从远程服务器获取指定的几个binlog,也可将不断生成的binlog保存到本地。指定此选项,代表只要远程服务器不关闭或者连接未断开,mysqlbinlog就会不断的复制远程服务器上的binlog。

mysql-bin.000001:代表从哪个binlog开始复制。

除了以上选项外,还有以?#24405;?#20010;选项需要注意:

–stop-never-slave-server-id:在备份远程服务器的binlog时,mysqlbinlog本质上就相当于一个从服务器,该选项就是用来指定从服务器的server-id的。默认为-1。

–to-last-log:代表mysqlbinlog不仅能够获取指定的binlog,还能获取其后生成的binlog,获取完了,才终止。如果指定了–stop-never选项则会隐式打开–to-last-log选项。

–result-file:用于设置远程服务器的binlog,保存到本地?#37027;?#32512;。譬如对于mysql-bin.000001,如果指定–result-file=/test/backup-,则保存到本地后的文件名为/test/backup-mysql-bin.000001。注意:如果将–result-file设置为目录,则一定要带上目录?#25351;?#31526;“/”。譬如–result-file=/test/,而不是–result-file=/test,不然保存到本地的文件名为/testmysql-bin.000001。

 

 

 

 

我们现在要结合Binlog来恢复,但前提要找出误操作前的pos点

 

通过事件的位置来恢复(不完全恢复)

 

  1. [root@localhost ~]# mysqlbinlog -v –base64-output=DECODE-ROWS localhost-bin.000002 |grep -C 10 -i "drop database"

  2. ### INSERT INTO `xuanzhi`.`tb1`

  3. ### SET

  4. ### @1=5

  5. ### @2=’ee’

  6. # at 290

  7. #170327 21:10:55 server id 1313306 end_log_pos 321 CRC32 0x825a2f99 Xid = 78

  8. COMMIT/*!*/;

  9. # at 321  <–开始

  10. #170327 21:19:25 server id 1313306 end_log_pos 422   <–结束点 CRC32 0x8c139cac Query thread_id=2 exec_time=0 error_code=0

  11. SET TIMESTAMP=1490620765/*!*/;

  12. drop database xuanzhi

 

上面的黄色加粗的就是,一个是start-position,一个是stop-position

 

从上面可以看到,误操作前的pos点是321,那我们现在通过binlog来进行数据恢复:

  1. [root@localhost mysql-5.6]# mysqlbinlog –start-position=329 –stop-position=321 localhost-bin.000001 localhost-bin.000002 |mysql -uroot -p123456 xuanzhi

–start-position是备份后记录下的pos点,

–stop-position是误操前的pos点,

如果多个binlog文件,那么start-position是第一个binlog文件的pos点,stop-position是最后一个binlog的pos点

 

通过事件的时间来恢复(不完全恢复)

我们可以通过参数–start-datetime–stop-datetime指定恢复binlog日志的起?#25925;?#38388;点,时间使用DATETIME格式。


    比如在时间点2005-04-20 10:00:00我们删除掉一个库,我?#19988;?#24674;复该时间点前的所有日志


[root@localhost /]# mysqlbinlog –stop-datetime="2005-04-20 9:59:59" /usr/local/mysql/data/binlog.123456 | mysql -u root

    我们可能几个小时后才发现该错误,后面又有一系列的增删查改等操作,我们还需要恢复后续的binlog,我们可以指定起始时间

 

组合

和基于时间点恢复类是,但是更加精确.因为同一时间点可能有多条SQL语句执行;

例:

#mysqlbinlog –start-date="2010-10-31 9:55:00"  –stop-date="2010-10-31 10:05:00" /usr/local/mysql/var/mysql-bin.000013 > /tmp/mysql_restore.sql

该命令将在/tmp/目录下创建小的文件,编辑它?#19994;?#38169;误语句前后的位置号,例如前后位置号分别是368312 和 368315

(2)恢复了以前的备份文件后,输入

#mysqlbinlog –stop-position="368312" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p

#mysqlbinlog –start-position="368315" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot –p

 

总结:

        一、在恢复全备数据之前必须将该binlog文件移出,否则恢复过程中,会继续写入语句到binlog,最终导致增量恢复数据部分变得比较混乱

        二、做好数据文件及binlog的备份至关重要,但不是备份完就算了,要定期进行数据恢复测试或演练

        三、恢复时建议对外停止更新,即禁止更新数据库

]]>
http://www.rygqfb.tw/?feed=rss2&p=4188 0
mysql备份还原-基于binlog的增量备份还原 http://www.rygqfb.tw/?p=4187 http://www.rygqfb.tw/?p=4187#respond Mon, 19 Aug 2019 06:19:50 +0000 http://www.rygqfb.tw/?p=4187  

启用binlog

vi my.cnf

log-bin=/var/lib/mysql/mysql-bin.log,如果是这样的话log-bin=mysql-bin.log默认在datadir目录下面

[root@BlackGhost mysql]# ls |grep mysql-bin
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.000004
mysql-bin.000005
mysql-bin.000006
mysql-bin.index

 

查看mysql-bin.000002这样的文件里面到底是什么东西

[root@BlackGhost mysql]# mysqlbinlog   /var/lib/mysql/mysql-bin.000002 > /tmp/add.sql

binlog增量备份和增量还原

1,增量备份

既然我们知道了,mysql里面新增加的数据在mysql-bin这样的文件里面,我们只要把mysql-bin这样的文件进行备份就可以了。

cp /var/lib/mysql/mysql-bin* /data/mysql_newbak/

 

我们现在要结合Binlog来恢复,但前提要找出误操作前的pos点

 

通过事件的位置来恢复(不完全恢复)

 

  1. [root@localhost ~]# mysqlbinlog -v –base64-output=DECODE-ROWS localhost-bin.000002 |grep -C 10 -i "drop database"

  2. ### INSERT INTO `xuanzhi`.`tb1`

  3. ### SET

  4. ### @1=5

  5. ### @2=’ee’

  6. # at 290

  7. #170327 21:10:55 server id 1313306 end_log_pos 321 CRC32 0x825a2f99 Xid = 78

  8. COMMIT/*!*/;

  9. # at 321  <–开始

  10. #170327 21:19:25 server id 1313306 end_log_pos 422   <–结束点 CRC32 0x8c139cac Query thread_id=2 exec_time=0 error_code=0

  11. SET TIMESTAMP=1490620765/*!*/;

  12. drop database xuanzhi

 

上面的黄色加粗的就是,一个是start-position,一个是stop-position

 

从上面可以看到,误操作前的pos点是321,那我们现在通过binlog来进行数据恢复:

  1. [root@localhost mysql-5.6]# mysqlbinlog –start-position=329 –stop-position=321 localhost-bin.000001 localhost-bin.000002 |mysql -uroot -p123456 xuanzhi

–start-position是备份后记录下的pos点,

–stop-position是误操前的pos点,

如果多个binlog文件,那么start-position是第一个binlog文件的pos点,stop-position是最后一个binlog的pos点

 

通过事件的时间来恢复(不完全恢复)

我们可以通过参数–start-datetime–stop-datetime指定恢复binlog日志的起?#25925;?#38388;点,时间使用DATETIME格式。

    比如在时间点2005-04-20 10:00:00我们删除掉一个库,我?#19988;?#24674;复该时间点前的所有日志

[root@localhost /]# mysqlbinlog –stop-datetime="2005-04-20 9:59:59" /usr/local/mysql/data/binlog.123456 | mysql -u root

    我们可能几个小时后才发现该错误,后面又有一系列的增删查改等操作,我们还需要恢复后续的binlog,我们可以指定起始时间

 

组合

和基于时间点恢复类是,但是更加精确.因为同一时间点可能有多条SQL语句执行;

例:

#mysqlbinlog –start-date="2010-10-31 9:55:00"  –stop-date="2010-10-31 10:05:00" /usr/local/mysql/var/mysql-bin.000013 > /tmp/mysql_restore.sql

该命令将在/tmp/目录下创建小的文件,编辑它?#19994;?#38169;误语句前后的位置号,例如前后位置号分别是368312 和 368315

(2)恢复了以前的备份文件后,输入

#mysqlbinlog –stop-position="368312" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p

#mysqlbinlog –start-position="368315" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot –p

 

总结:

        一、在恢复全备数据之前必须将该binlog文件移出,否则恢复过程中,会继续写入语句到binlog,最终导致增量恢复数据部分变得比较混乱

        二、做好数据文件及binlog的备份至关重要,但不是备份完就算了,要定期进行数据恢复测试或演练

        三、恢复时建议对外停止更新,即禁止更新数据库

]]>
http://www.rygqfb.tw/?feed=rss2&p=4187 0
理解–single-transaction 和–lock-all-tables http://www.rygqfb.tw/?p=4186 http://www.rygqfb.tw/?p=4186#respond Mon, 19 Aug 2019 04:25:07 +0000 http://www.rygqfb.tw/?p=4186 在mysqldump过程中,之前其实一直不是很理解为什么加了–single-transaction就能保证innodb的数据是完全一致的,而myisam引擎无法保证,必须加–lock-all-tables,前段时间抽?#38556;?#32454;地查看了整个mysqldump过程。

理解master-data和–dump-slave
–master-data=2表示在dump过程中记录主库的binlog和pos点,并在dump文件中注释掉这一行;

–master-data=1表示在dump过程中记录主库的binlog和pos点,并在dump文件中不注释掉这一行,即恢复时会执行;

–dump-slave=2表示在dump过程中,在从库dump,mysqldump进程也要在从库执行,记录当时主库的binlog和pos点,并在dump文件中注释掉这一行;

–dump-slave=1表示在dump过程中,在从库dump,mysqldump进程也要在从库执行,记录当时主库的binlog和pos点,并在dump文件中不注释掉这一行;

注意:在从库?#29616;?#34892;备份时,即–dump-slave=2,这时整个dump过程都是stop io_thread的状态

 

深入理解–single-transaction:
打开general_log,准备一个数据量较小的db,开启备份,添加–single-transaction和–master-data=2参数,查看general_log,信息如下,每一步添加了我的理解

 

整个dump过程是同一个连接id 32,这样能保证在设置session级别的变量的时候不影响到其他连接

thread_id: 32
argument: ucloudbackup@localhost on 
*************************** 14. row ***************************
thread_id: 32
argument: /*!40100 SET @@SQL_MODE=” */
*************************** 15. row ***************************
thread_id: 32
argument: /*!40103 SET TIME_ZONE=’+00:00′ */
*************************** 16. row ***************************
thread_id: 32
argument: FLUSH /*!40101 LOCAL */ TABLES
*************************** 17. row ***************************
thread_id: 32
argument: FLUSH TABLES WITH READ LOCK
批注:因为开启了–master-data=2,这?#26412;?#38656;要flush tables with read lock锁住全库,记录当时的master_log_file和master_log_pos点
*************************** 18. row ***************************
thread_id: 32
argument: SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
批注:–single-transaction参数的作用,设置事务的隔离级别为可重复读,即REPEATABLE READ,这样能保证在一个事务中所有相同的查询读取到同样的数据,也就大概保证了在dump期间,如果其他innodb引擎的线程修改了表的数据并提交,对该dump线程的数据并无影响,然而这个还不够,还需要看下一条
*************************** 19. row ***************************
thread_id: 32
argument: START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
这时开启一个事务,并且设置WITH CONSISTENT SNAPSHOT为快照级别(如果mysql版本高于某一个版本值,我还不大清楚40100代表什么版本)。想象一下,如果只是可重复读,那么在事务开始时还没dump数据时,这时其他线程修改并提交了数据,那么这时第一次查询得到的结果是其他线程提交后的结果,而WITH CONSISTENT SNAPSHOT能够保证在事务开启的时候,第一次查询的结果就是事务开始时的数据A,即使这时其他线程将其数据修改为B,查的结果依然是A,具体的测试看我下面的测试结果
*************************** 20. row ***************************
thread_id: 32
argument: SHOW MASTER STATUS
这时候执行这个命令来记录当时的master_log_file和master_log_pos点,注意为什么这个时候记录,而不是再18 row和19 row之间?#22270;?#24405;,个人认为应该都是可以的,这里是测试结果,start  transaction并不会产生binlog的移动,而18 row和19 row的动作也在同一个thread id中
mysql> show master status;
+——————+———-+————–+——————+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000003 |     1690 |              |                  |
+——————+———-+————–+——————+
1 row in set (0.00 sec)

*************************** 21. row ***************************
thread_id: 32
argument: UNLOCK TABLES
等记录完成后,就立即释放了,因为现在已经在一个事务中了,其他线程再修改数据已经无所谓,在本线程中已经是可重复读,这也是这一步必须在19 rows之后的原因,如果20 rows和21 rows都在19 rows之前的话就不行了,因为这时事务还没开启,一旦释放,其他线程立即就可以更改数据,从而无法保证得到事务开启时最准确的pos点。

*************************** 22. row ***************************
thread_id: 32
argument: SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘UNDO LOG’ AND FILE_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IN (SELECT DISTINCT LOGFILE_GROUP_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘DATAFILE’ AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA=’mysql’ AND TABLE_NAME IN (‘user’))) GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE ORDER BY LOGFILE_GROUP_NAME
*************************** 23. row ***************************
thread_id: 32
argument: SELECT DISTINCT TABLESPACE_NAME, FILE_NAME, LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL_SIZE, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘DATAFILE’ AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA=’mysql’ AND TABLE_NAME IN (‘user’)) ORDER BY TABLESPACE_NAME, LOGFILE_GROUP_NAME
*************************** 24. row ***************************
thread_id: 32
argument: mysql
*************************** 25. row ***************************
thread_id: 32
argument: SHOW TABLES LIKE ‘user’
*************************** 26. row ***************************
thread_id: 32
argument: show table status like ‘user’
dump表以前都需要show一下各自信息,确保表,视图等不损坏,可用,每一步错了mysqldump都会报错并中?#24076;?#32473;出对应的错误码,常见的myqldump错误请参考我的另外一篇blog http://blog.csdn.net/cug_jiang126com/article/details/49359699
*************************** 27. row ***************************
thread_id: 32
argument: SET OPTION SQL_QUOTE_SHOW_CREATE=1
*************************** 28. row ***************************
thread_id: 32
argument: SET SESSION character_set_results = ‘binary’
*************************** 29. row ***************************
thread_id: 32
argument: show create table `user`
*************************** 30. row ***************************
thread_id: 32
argument: SET SESSION character_set_results = ‘utf8’
*************************** 31. row ***************************
thread_id: 32
argument: show fields from `user`
*************************** 32. row ***************************
thread_id: 32
argument: SELECT /*!40001 SQL_NO_CACHE */ * FROM `user`
这就是我们show processlist时看到的信息,而数据是怎么通过一条select语句就dump到本地文件里的呢,并且还转成?#19978;?#24212;的create和insert语句,这就是mysqldump这个客户端工具的工作了,这里不做?#33268;?
*************************** 33. row ***************************
最后并没有看到commit,因为在整个事务中,其实并没?#34892;?#25913;任何数据,只是为了保证可重复读得到备份时间点一致性的快照,dump完成后提交不提交应该无所谓了。

 

myisam引擎为什?#27425;?#27861;保证在–single-transaction下得到一致性的备份?
因为它压根就不支持事务,自然就无法实现上述的过程,虽然添加了–single-transaction参数的myisam表处理过程和上面的完全一致,但?#19988;?#20026;不支持事务,在整个dump过程中无法保证可重复读,无法得到一致性的备份。而innodb在备份过程中,虽然其他线程也在写数据,但是dump出来的数据能保证是备份开始时那个binlog pos的数据。

myisam引擎要保证得到一致性的数据的话,他是如何实现的呢?
它是通过添加–lock-all-tables,这样在flush tables with read lock后,直到整个dump过程结束,断开线程后才会unlock tables释放锁(没必要主动发unlock tables指令),整个dump过程其他线程不可写,从而保证数据的一致性

如果我一定要在mysiam引擎中也添加–single-transaction参数,再用这个备份去创建从库或恢复到指定时间点,会有什么样的影响?
我个人的理解是如果整个dump过程中只有简单的insert操作,是没有关系的,期间肯定会有很多的主键重?#21019;?#35823;,直接跳过或忽略就好了。如果是update操作,那就要出问题了,分几种情况考虑

1) 如果是基于时间点的恢复,假设整个dump过程有update a  set id=5 where id=4之类的操作,相当于重复执行两次该操作,应该问题不大
2) 如果是创建从库,遇到上面的sql从库会报错,?#20063;?#21040;该记录,这时跳过就好

3)不管是恢复?#25925;?#21019;建从库,如果dump过程中有update a set id=id+5 之类的操作,那就有问题,重复执行两次,数据全变了。

深入理解–lock-all-tables
打开general_log,准备一个数据量较小的db,开启备份,添加–lock-all-tables(其实也是默认设置)和–master-data=2参数,查看general_log,信息如下,理解–lock-all-tables怎么保证数据一致性

 

mysql> select thread_id,argument from general_log  where thread_id=185\G
*************************** 1. row ***************************
thread_id: 185
argument: ucloudbackup@10.10.108.15 on 
*************************** 2. row ***************************
thread_id: 185
argument: /*!40100 SET @@SQL_MODE=” */
*************************** 3. row ***************************
thread_id: 185
argument: /*!40103 SET TIME_ZONE=’+00:00′ */
*************************** 4. row ***************************
thread_id: 185
argument: FLUSH /*!40101 LOCAL */ TABLES
*************************** 5. row ***************************
thread_id: 185
argument: FLUSH TABLES WITH READ LOCK
这里flush tables with read lock之后就不会主动unlock tables,保证整个dump过程整个db数据不可更改,也没有事务的概念了
*************************** 6. row ***************************
thread_id: 185
argument: SHOW MASTER STATUS
同样记录主库的位置
*************************** 7. row ***************************
thread_id: 185
argument: SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘UNDO LOG’ AND FILE_NAME IS NOT NULL GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE ORDER BY LOGFILE_GROUP_NAME
*************************** 8. row ***************************
thread_id: 185
argument: SELECT DISTINCT TABLESPACE_NAME, FILE_NAME, LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL_SIZE, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘DATAFILE’ ORDER BY TABLESPACE_NAME, LOGFILE_GROUP_NAME
*************************** 9. row ***************************
thread_id: 185
argument: SHOW DATABASES
*************************** 10. row ***************************
thread_id: 185
argument: jjj
*************************** 11. row ***************************
thread_id: 185
argument: SHOW CREATE DATABASE IF NOT EXISTS `jjj`
————————————————
版权声明:本文为CSDN博主「rewiner120」的原?#27425;?#31456;,遵循CC 4.0 by-sa版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/rewiner120/article/details/70598828

]]>
http://www.rygqfb.tw/?feed=rss2&p=4186 0
一看必会系列:k8s ?#24223;?4 日志收集 efk 实战 http://www.rygqfb.tw/?p=4185 http://www.rygqfb.tw/?p=4185#respond Sun, 11 Aug 2019 17:12:25 +0000 http://www.rygqfb.tw/?p=4185 从官方下载对应yaml
https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/fluentd-elasticsearch

es-statefulset.yaml:      – image: quay.io/fluentd_elasticsearch/elasticsearch:v7.2.0
es-statefulset.yaml:      – image: alpine:3.6
fluentd-es-ds.yaml:        image: quay.io/fluentd_elasticsearch/fluentd:v2.6.0
kibana-deployment.yaml:        image: docker.elastic.co/kibana/kibana-oss:7.2.0

docker pull registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:kibana-oss7.2.0
docker pull registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:fluentdv2.6.0
docker pull registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:elasticsearchv7.2.0

docker tag registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:kibana-oss7.2.0 \
           docker.elastic.co/kibana/kibana-oss:7.2.0
docker tag registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:fluentdv2.6.0 \
           quay.io/fluentd_elasticsearch/fluentd:v2.6.0
docker tag registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:elasticsearchv7.2.0 \
           quay.io/fluentd_elasticsearch/elasticsearch:v7.2.0

-rw-r–r–  1 root root      382 Apr  3 23:28 es-service.yaml
-rw-r–r–  1 root root     2900 Apr  4 04:15 es-statefulset.yaml
-rw-r–r–  1 root root    16124 Apr  3 23:28 fluentd-es-configmap.yaml
-rw-r–r–  1 root root     2717 Apr  4 06:19 fluentd-es-ds.yaml
-rw-r–r–  1 root root     1166 Apr  4 05:46 kibana-deployment.yaml
-rw-r–r–  1 root root      272 Apr  4 05:27 kibana-ingress.yaml  #这个在后面
-rw-r–r–  1 root root      354 Apr  3 23:28 kibana-service.yaml

特别注意,一定要按照yaml里的文件来下载image不然会有各种错

先执行这个
kubectl create -f fluentd-es-configmap.yaml
configmap/fluentd-es-config-v0.2.0 created

再执行
[root@k8s-master elk]# kubectl create -f fluentd-es-ds.yaml
serviceaccount/fluentd-es created
clusterrole.rbac.authorization.k8s.io/fluentd-es created
clusterrolebinding.rbac.authorization.k8s.io/fluentd-es created
daemonset.apps/fluentd-es-v2.5.0 created

[root@k8s-master elk]# kubectl get pod -n kube-system |grep flu
fluentd-es-v2.5.0-hjzw8                 1/1     Running   0          19s
fluentd-es-v2.5.0-zmlm2                 1/1     Running   0          19s
[root@k8s-master elk]#

再启动elasticsearch
[root@k8s-master elk]# kubectl create -f es-statefulset.yaml
serviceaccount/elasticsearch-logging created
clusterrole.rbac.authorization.k8s.io/elasticsearch-logging created
clusterrolebinding.rbac.authorization.k8s.io/elasticsearch-logging created
statefulset.apps/elasticsearch-logging created
[root@k8s-master elk]# kubectl create -f es-service.yaml
service/elasticsearch-logging created
[root@k8s-master elk]#

[root@k8s-master elk]# kubectl get pod -n kube-system |grep elas
elasticsearch-logging-0                 1/1     Running   0          11s
elasticsearch-logging-1                 1/1     Running   0          8s
[root@k8s-master elk]#

再高动 kibana/kibana
kubectl create -f kibana-deployment.yaml
kubectl get pod -n kube-system
kubectl create -f kibana-service.yaml

验证
[root@k8s-master elk]# kubectl get pod,svc -n kube-system |grep kiba
pod/kibana-logging-65f5b98cf6-2p8cj         1/1     Running   0          46s

service/kibana-logging          ClusterIP   10.100.152.68   <none>        5601/TCP        21s
[root@k8s-master elk]#

查看集群信息
[root@k8s-master elk]# kubectl cluster-info
Elasticsearch is running at https://192.168.10.68:6443/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
Kibana is running at https://192.168.10.68:6443/api/v1/namespaces/kube-system/services/kibana-logging/proxy

因为只开了 容器端口,在外部机器上是无法访问的。有以?#24405;?#31181;方法来访问

1.开proxy  在master上开
#这玩意是前台执行的,退出后就没了。–address 是master的Ip 实际上哪台上面都行
kubectl proxy –address=’192.168.10.68′ –port=8085 –accept-hosts=’^*$’

如需后台运?#23567;?#20351;用。 nohup  kubectl proxy –address=’192.168.10.68′ –port=8085 –accept-hosts=’^*$’ *
在master上查看端口是否开启
netstat -ntlp |grep 80
tcp        0      0 192.168.10.68:2380      0.0.0.0:*               LISTEN      8897/etcd          
tcp        0      0 192.168.10.68:8085      0.0.0.0:*               LISTEN      16718/kubectl  

直接浏览器验证
http://192.168.10.68:8085/api/v1/namespaces/kube-system/services/kibana-logging/proxy/app/kibana#/home/tutorial_directory/sampleData?_g=()
出页面即正常

进去kibana后操作出图
1.点击左边management
2. 建立index Create index pattern
3. 输入* 查看具体的日志名
4.  例如 logstash-2019.03.25 ,改成logstash-* 下一步到完成
4.1 一定要把那个 星星点一下, 设为index默认以logstash-*
5. discover 就可以看到日志了

验证结果,以下为正常,没有https 要注意
curl http://192.168.10.68:8085/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/
{
  "name" : "bc30CKf",
  "cluster_name" : "docker-cluster",
  "cluster_uuid" : "C3oV5BnMTByxYltuuYjTjg",
  "version" : {
    "number" : "6.7.0",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "8453f77",
    "build_date" : "2019-03-21T15:32:29.844721Z",
    "build_snapshot" : false,
    "lucene_version" : "7.7.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

方法二:

[root@k8s-master elk]# kubectl get ingress -n kube-system -o wide
NAME             HOSTS           ADDRESS   PORTS   AGE
kibana-logging   elk.ccie.wang             80      6m42s

可以是可以。但是会报 404 这个需要再查下问题在哪

创建ingress
配置文件如下 kibana-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kibana-logging-ingress
  namespace: kube-system
spec:
  rules:
  – host: elk.ccie.wang
    http:
      paths:
      – path: /
        backend:
          serviceName: kibana-logging
          servicePort: 5601

kubectl create -f kibana-ingress.yaml

方法三:

修改 kibana-service.yaml 可直接访问http://node:nodeport

11 spec:
12   ports:
13   – port: 5601
14     protocol: TCP
15     targetPort: ui
16     #add nodeport
17   type: NodePort

验证文件信息
[root@k8s-master elk]# kubectl get -f fluentd-es-ds.yaml
NAME                        SECRETS   AGE
serviceaccount/fluentd-es   1         85s

NAME                                               AGE
clusterrole.rbac.authorization.k8s.io/fluentd-es   85s

NAME                                                      AGE
clusterrolebinding.rbac.authorization.k8s.io/fluentd-es   85s

NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/fluentd-es-v2.5.0   2         2         2       2            2           <none>          85s
[root@k8s-master elk]#

----------报错

[root@k8s-master elk]# kubectl get pod -n kube-system |grep elas
elasticsearch-logging-0                 0/1     ErrImagePull   0          71s
[root@k8s-master elk]#
拉境像报错

      containers:
      #将下面改成
      #- image: gcr.io/fluentd-elasticsearch/elasticsearch:v6.6.1
      – image: reg.ccie.wang/library/elk/elasticsearch:6.7.0

—————-知识扩展
1. fluentd
怎么使用这个镜像

docker run -d -p 24224:24224 -p 24224:24224/udp -v /data:/fluentd/log fluent/fluentd:v1.3-debian-1

默认的配置如下
监听端口 24224
存储标记为 docker.** 到 /fluentd/log/docker.*.log (and symlink docker.log)
存储其它日志到 /fluentd/log/data.*.log (and symlink data.log)

?#27604;?#20063;能自定议参数

docker run -ti –rm -v /path/to/dir:/fluentd/etc fluentd -c /fluentd/etc/配置文件 -v

第一个-v ?#20197;?path/to/dir到容器里的/fluentd/etc

-c 前的是容器名 告诉 fluentd去哪找这个配置文件
第二个-v 传递详细的配置信息给 fluented

切换运行用户 foo

docker run -p 24224:24224 -u foo -v …

]]>
http://www.rygqfb.tw/?feed=rss2&p=4185 0
一看必会系列:k8s ?#24223;?3 wordpress php nginx mysql 全家?#23433;?#32626; http://www.rygqfb.tw/?p=4184 http://www.rygqfb.tw/?p=4184#respond Sun, 11 Aug 2019 12:47:12 +0000 http://www.rygqfb.tw/?p=4184 来搞一套完整的PHP MYSQL INGRESS 在K8S上的部署教程

组件PHP WORDPRESS
MYSQL
INGRESS
K8S
DOCKER

一。建mysql rc 与sr 服务

创建RC
[root@master yaml]# cat mysql-rc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: mysql-rc
  labels:
    name: mysql-pod-lb
spec:
  replicas: 1
  selector:
    name: mysql-pod-lb
  template:
    metadata:
      labels:
        name: mysql-pod-lb
    spec:
     containers:
     – name: mysql-name
       image: daocloud.io/library/mysql:5.7.4
       ports:
       – containerPort: 3306
       env:   #密码一定要不然报错
       – name: MYSQL_ROOT_PASSWORD
         value: "mysql"
       volumeMounts:    #本地卷 ?#20197;?#21040;容器内的数据目录 /var/lib/mysql
       – mountPath: /var/lib/mysql
         name: mysqldata
     volumes:     #创建本地卷,将数据?#19994;?#26412;地,数据?#24535;?#21270;
      – name: mysqldata
        hostPath:
          path: /data/mysql_data

创建service
[root@master yaml]# cat mysql-svc.yaml
apiVersion: v1                                                                             
kind: Service
metadata:                                                                                  
  name: mysql-svc                                                                              
  labels:
    name: mysql-svc-lb
spec:                                                                                      
  type: NodePort
  ports:
    – port: 3306
      nodePort: 30013
  selector:
    name: mysql-pod-lb

2  生成mysql

  503  kubectl apply -f mysql-rc.yaml
  506  kubectl apply -f mysql-svc.yaml

验证
[root@master yaml]# kubectl get pod -o wide |grep mysql
mysql-rc-hjtth          1/1     Running       0          34m     92.68.111.13    slave002   <none>           <none>
#可以直接进容器进行验证服务是否起来

[root@master yaml]# kubectl get svc |grep mysql
mysql-svc      NodePort    10.109.223.210   <none>        3306:30013/TCP   33m
[root@master yaml]#
[root@master yaml]# kubectl get rc |grep mysql
mysql-rc      1         1         1       35m
[root@master yaml]#

到目NODE 上查看目录是否生成
[root@slave002 ~]# !ll
ll /data/mysql_data/
total 188440
-rw-rw—-. 1 polkitd input       56 Aug 11 05:23 auto.cnf
-rw-rw—-. 1 polkitd input 79691776 Aug 11 05:52 ibdata1
-rw-rw—-. 1 polkitd input 50331648 Aug 11 05:52 ib_logfile0
-rw-rw—-. 1 polkitd input 50331648 Aug 11 05:23 ib_logfile1
-rw-rw—-. 1 polkitd input 12582912 Aug 11 05:23 ibtmp1
drwx——. 2 polkitd input     4096 Aug 11 05:23 mysql
-rw-rw—-. 1 polkitd input        2 Aug 11 05:23 mysql-rc-hjtth.pid
drwx——. 2 polkitd input     4096 Aug 11 05:23 performance_schema
drwx——. 2 polkitd input     4096 Aug 11 05:46 wordpress
[root@slave002 ~]#

二 创建 wordpress 应用

1.创建RC
[root@master yaml]# cat wordpress-rc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: wp-rc
  labels:
    name: wp-pod-lb
spec:
  replicas: 1
  selector:
    name: wp-pod-lb
  template:
    metadata:
      labels:
        name: wp-pod-lb
    spec:
     containers:
     – name: wp-name
       image: daocloud.io/daocloud/dao-wordpress:latest
       ports:
       – containerPort: 80
2.创建service
[root@master yaml]# cat wordpress-svc.yaml
apiVersion: v1                                                                             
kind: Service
metadata:                                                                                  
  name: wp-svc                                                                              
  labels:
    name: wp-svc-lb
spec:                                                                                      
  type: NodePort
  ports:
    – port: 80
      nodePort: 30012
  selector:
    name: wp-pod-lb
[root@master yaml]#

三 创建 ingress 进行入站转发

[root@master yaml]# cat wordpress-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-wp
spec:
  rules:
  – host: wp.ccie.wang   #提前做域名解析
    http:
      paths:
      – path: /
        backend:
          serviceName: wp-svc
                  #这里是上面服务的端口用kubectl get pods 进行查看
                  #意思是将请求转发到 frontend-svc 的80端口,和nginx 的upstream 一样
          servicePort: 80
[root@master yaml]#

?#27169;?WORDPRESS  应用初始化

1 访问http://wp.ccie.wang/  进入初始化页面
2 输入MYSQL 信息

usrname root
password mysql
host    mysql-rc (这里写rc的名字即可)
数据库  wordpress (需要提前建立)

密码

root
root!k8$-Mysql

进入容器修改mysql权限

[root@slave002 ~]# docker ps |grep mysql
8c259e35def5        aa5364eb3d85                         "/entrypoint.sh mysq…"   10 minutes ago      Up 10 minutes                           k8s_mysql-name_mysql-rc-hjtth_default_ae1b949b-bc19-11e9-8452-000c2958de12_0
2ac851ecc85c        k8s.gcr.io/pause:3.1                 "/pause"                 10 minutes ago      Up 10 minutes                           k8s_POD_mysql-rc-hjtth_default_ae1b949b-bc19-11e9-8452-000c2958de12_0
[root@slave002 ~]#

进入
[root@slave002 ~]# docker  exec -it 8c259e35def5 /bin/bash
进入mysql
root@mysql-rc-hjtth:/usr/local/mysql# mysql -u root -pmysql
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 9
Server version: 5.7.4-m14 MySQL Community Server (GPL)

#修改权限
mysql> SET PASSWORD FOR `root`@`%` = PASSWORD(‘********d’);

CREATE DATABASE `wordpress` CHARACTER SET ‘utf8’ COLLATE ‘utf8_bin’;

验证

1,先发一篇文章 k8s ?#24223;?3 k8s wordpress nginx mysql 部署

2。进行验证,成功
[root@master yaml]# curl http://wp.ccie.wang/ -s |grep ?#24223;?3  |tail -n 1
                <a href="http://wp.ccie.wang/2019/08/11/k8s-%e7%bb%83%e4%b9%a033-k8s-wordpress-nginx-mysql-%e9%83%a8%e7%bd%b2/">k8s ?#24223;?3 k8s wordpress nginx mysql 部署</a>

成功 一套完整的PHP MYSQL INGRESS 就完成了

]]>
http://www.rygqfb.tw/?feed=rss2&p=4184 0
用于主题检测的临?#27604;?#24535;(ce8146ce-592e-4ab8-8f03-cf04233792a1 – 3bfe001a-32de-4114-a6b4-4005b770f6d7) http://www.rygqfb.tw/?p=4183 http://www.rygqfb.tw/?p=4183#respond Sun, 11 Aug 2019 12:43:16 +0000 http://www.rygqfb.tw/?p=4183 这?#19988;?#20010;未删除的临?#27604;?#24535;。请手动删除它。(36ae9a1c-f1d6-469c-8299-26f8ebf48cab – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

]]>
http://www.rygqfb.tw/?feed=rss2&p=4183 0
TCPPING http://www.rygqfb.tw/?p=4182 http://www.rygqfb.tw/?p=4182#respond Thu, 01 Aug 2019 07:19:19 +0000 http://www.rygqfb.tw/?p=4182 https://github.com/deajan/tcpping

 

禁ping?#37027;?#20917;下如何ping测试连通性来速度 使用TCPPING

 

Installation

sudo wget -O /usr/bin/tcpping https://raw.githubusercontent.com/deajan/tcpping/master/tcpping ; chmod 755 /usr/bin/tcpping

Usage

Example command smokeping would use

使用方式

tcpping -C -x 5 baidu.com 80

]]>
http://www.rygqfb.tw/?feed=rss2&p=4182 0
rsync: chgrp failed: Operation not permitted (1) http://www.rygqfb.tw/?p=4181 http://www.rygqfb.tw/?p=4181#respond Tue, 23 Jul 2019 06:57:32 +0000 http://www.rygqfb.tw/?p=4181 用rsync 同步本地目录到远程服务器

rsync -ar  /data/service/  hadoop@192.168.10.156:/data/service/
rsync: chgrp "/data/service/." failed: Operation not permitted (1)
rsync: recv_generator: mkdir "/data/service/bin" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/data/service/etc" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/data/service/include" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/data/service/lib" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/data/service/libexec" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/data/service/sbin" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/data/service/share" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: mkstemp "/data/service/.LICENSE.txt.AUGp3J" failed: Permission denied (13)
rsync: mkstemp "/data/service/.NOTICE.txt.X5Qf9z" failed: Permission denied (13)
rsync: mkstemp "/data/service/.README.txt.ekL7eq" failed: Permission denied (13)

原因  hadoop用户没有目录的操作权,将目的目录修改为 hadoop所有者
hadoop@192.168.10.156:/data/service/

查看各台机器配置
java ~]# cat /etc/rsyncd.conf |grep -v ^#
uid = 1000
gid = 1000

查看目的目录的权限
service]# ll /data
total 0
drwxr-xr-x 2 root root 6 Jul 23 03:19 service

修改1
修改权限
data]# chown -R 1000:1000 /data/
data]# ll /data
total 0
drwxr-xr-x 2 hadoop hadoop 6 Jul 23 03:19 service

测试
java ~]# rsync -ar  /data/service/  hadoop@192.168.10.156:/data/service/

同步完成无报错

]]>
http://www.rygqfb.tw/?feed=rss2&p=4181 0
30选5玩法
11选5计划软件哪个好 北京pk10稳定版计划 七乐彩专家预测号码 3d单选 线上彩票平台怎么赚钱 技巧之稳赚不赔方法 北京时时吧 pk10冠军无马二期必中计划 六肖中特期期谁白小姐 千里马计划怎么避免连挂