https://www.161616.top/tags/databases/ Recent content in Databases on Cylon's Collection Hugo -- 0.125.7 zh Sat, 18 Mar 2023 23:00:36 +0800 https://www.161616.top/ch11-sssd/ Tue, 15 Nov 2022 00:00:00 +0000 https://www.161616.top/ch11-sssd/ openldap合集 ch1 理解ldap - 什么是ldap ch2 理解ldap - OpenLDAP安装 ch3 理解ldap - OpenLDAP客户端命令行使用 ch4 理解ldap - OpenLDAP架构与Schema设计 ch5 理解ldap - OpenLDAP使用SSL/TLS通信安全 ch6 理解ldap - OpenLDAP中的4种复制机制 ch7 理解ldap - OpenLDAP访问控制(ACL) ch8 理解ldap - OpenLDAP备份与恢复策略 ch9 理解ldap - openldap中的一些高级配置 ch10 理解ldap - Linux系统接入OpenLDAP做认证后端 ch11 理解ldap - 使用SSSD接入OpenLDAP实现身份验证 Overview SSSD (System Security Services Daemon) 是一套用于远程身份验证的套件服务，为使用SSSD服务的客户端提供了远程访问身份认证服务来获取权限，其后端包括AD, LDAP等，本文将围绕下列方向来阐述SSSD： 为什么需要SSSD，以及使用SSSD来解决什么 使用SSSD的好处 SSSD服务工作原理及架构 如何在Linux上配置SSSD+LDAP 为什么需要SSSD SSSD设计主要是为了传统使用身份认证服务，例如PAM+NSS架构中存在的一些问题： PAM+NSS扩展性差，并配置较为复杂，尽管提供了 authconfig ，通常在大多数教程中以及不同的系统中配置都不相同 PAM+NSS不是真正意义上的离线身份认证，如果当 nslcd 或者 slapd 等服务异常时，无法完成用户认证 以及越来越多的后端，例如LDAP, AD, IPA, IdM,Kerberos等无法做到很好的适配 SSSD就是为了解决上述的问题，对于Linux平台中，SSSD拥有比传统PAM+NSS更好的优势： https://www.161616.top/ch10-linux-with-ldap/ Mon, 30 Sep 2019 00:00:00 +0000 https://www.161616.top/ch10-linux-with-ldap/ openldap合集 ch1 理解ldap - 什么是ldap ch2 理解ldap - OpenLDAP安装 ch3 理解ldap - OpenLDAP客户端命令行使用 ch4 理解ldap - OpenLDAP架构与Schema设计 ch5 理解ldap - OpenLDAP使用SSL/TLS通信安全 ch6 理解ldap - OpenLDAP中的4种复制机制 ch7 理解ldap - OpenLDAP访问控制(ACL) ch8 理解ldap - OpenLDAP备份与恢复策略 ch9 理解ldap - openldap中的一些高级配置 ch10 理解ldap - Linux系统接入OpenLDAP做认证后端 ch11 理解ldap - 使用SSSD接入OpenLDAP实现身份验证 Overview 如果要使Linux账号通过LDAP进行身份认证，就需要配置Linux的 身份验证模块 (Pluggable Authentication Modules) 与 名称服务交换系统 (Name Service Switch) 与LDAP交互。 PAM 和 NSS [3] NSS (name service switch) 通俗理解为是一个数据库系统，他作用是用于如何将操作系统与各种名称的解析机制关联起来，例如主机名，用户名，组名等内容的查找；例如UID查找使用 passwd 库，GID的查找使用 group 库，并且还可以告知查找的来源，如文件，LDAP等 https://www.161616.top/ch9-openldap-configuration/ Tue, 24 Sep 2019 00:00:00 +0000 https://www.161616.top/ch9-openldap-configuration/ openldap合集 ch1 理解ldap - 什么是ldap ch2 理解ldap - OpenLDAP安装 ch3 理解ldap - OpenLDAP客户端命令行使用 ch4 理解ldap - OpenLDAP架构与Schema设计 ch5 理解ldap - OpenLDAP使用SSL/TLS通信安全 ch6 理解ldap - OpenLDAP中的4种复制机制 ch7 理解ldap - OpenLDAP访问控制(ACL) ch8 理解ldap - OpenLDAP备份与恢复策略 ch9 理解ldap - openldap中的一些高级配置 ch10 理解ldap - Linux系统接入OpenLDAP做认证后端 ch11 理解ldap - 使用SSSD接入OpenLDAP实现身份验证 memberOf 默认情况下，openldap提供的Posixgroup组，实际上并不能很有效的区分组与用户之间的关系。而 memberOf 则可以有效地检索用户与组的关系 在OpenLDAP配置MemberOf模块 步骤一：可以检查在允许的slapd服务是否已经启用该模块 bash 1 $ slapcat -n 0 | grep olcModuleLoad 对于新部署的服务，可以按照如下方式添加 text 1 2 3 4 dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleload: memberof. https://www.161616.top/ch8-backup-and-restore/ Mon, 23 Sep 2019 00:00:00 +0000 https://www.161616.top/ch8-backup-and-restore/ openldap合集 ch1 理解ldap - 什么是ldap ch2 理解ldap - OpenLDAP安装 ch3 理解ldap - OpenLDAP客户端命令行使用 ch4 理解ldap - OpenLDAP架构与Schema设计 ch5 理解ldap - OpenLDAP使用SSL/TLS通信安全 ch6 理解ldap - OpenLDAP中的4种复制机制 ch7 理解ldap - OpenLDAP访问控制(ACL) ch8 理解ldap - OpenLDAP备份与恢复策略 ch9 理解ldap - openldap中的一些高级配置 ch10 理解ldap - Linux系统接入OpenLDAP做认证后端 ch11 理解ldap - 使用SSSD接入OpenLDAP实现身份验证 Overview 本章基于openldap 2.4+版本进行，主要讲解 openldap 的两种备份方法：备份openldap backend-database 文件，另一种方式为导出 LDIF 目录方式 Backup 备份部分将分为两种方式：使用基于 slapcat 导出目录文件方式，与直接备份数据库文件方式。 slapcat 是可用于导出 slapd 数据库中数据为LDAP交换格式的命令行工具，它可以导出 slapd 的配置也可以导出 slapd的数据。 slapcat 使用起来很简单，参数也是与 openldap 其他命令参数类似， https://www.161616.top/ch7-acl/ Sun, 22 Sep 2019 00:00:00 +0000 https://www.161616.top/ch7-acl/ openldap合集 ch1 理解ldap - 什么是ldap ch2 理解ldap - OpenLDAP安装 ch3 理解ldap - OpenLDAP客户端命令行使用 ch4 理解ldap - OpenLDAP架构与Schema设计 ch5 理解ldap - OpenLDAP使用SSL/TLS通信安全 ch6 理解ldap - OpenLDAP中的4种复制机制 ch7 理解ldap - OpenLDAP访问控制(ACL) ch8 理解ldap - OpenLDAP备份与恢复策略 ch9 理解ldap - openldap中的一些高级配置 ch10 理解ldap - Linux系统接入OpenLDAP做认证后端 ch11 理解ldap - 使用SSSD接入OpenLDAP实现身份验证 Overview 访问控制 (Access Control) 是对目录树中的IDT访问的权限控制。主要指 “谁” 应该能够 “访问记录” 在 “什么条件下” 他们应该能看到多少这样的记录，这些将是本节中阐述的问题 。 OpenLDAP控制目录数据访问的主要方法是 通过访问控制列表 (Access Control List)。使 slapd 服务端在处理来自客户端的请求时，会评估客户端是否具有访问所请求的 DIT 的权限。要执行此计算，slapd 将依次计算LDIF 中配置的每个ACL策略，以检查客户端是否有权限访问该 DIT。 https://www.161616.top/ch6-replication/ Fri, 20 Sep 2019 00:00:00 +0000 https://www.161616.top/ch6-replication/ openldap合集 ch1 理解ldap - 什么是ldap ch2 理解ldap - OpenLDAP安装 ch3 理解ldap - OpenLDAP客户端命令行使用 ch4 理解ldap - OpenLDAP架构与Schema设计 ch5 理解ldap - OpenLDAP使用SSL/TLS通信安全 ch6 理解ldap - OpenLDAP中的4种复制机制 ch7 理解ldap - OpenLDAP访问控制(ACL) ch8 理解ldap - OpenLDAP备份与恢复策略 ch9 理解ldap - openldap中的一些高级配置 ch10 理解ldap - Linux系统接入OpenLDAP做认证后端 ch11 理解ldap - 使用SSSD接入OpenLDAP实现身份验证 LDAP复制概述 openldap的复制 ( replication) 是可以将 LDAP DIT (Directory Information Tree) 同步更新复制到一个或多个LDAP (“ slapd ”) 系统，主要是用于实现备份或提升性能场景。在 openldap中，需要注意的一点是 “复制” 级别属于DIT级别而非LDAP服务级别运行。因此，在运行的一个服务 (slapd) 中的多个DIT，每一个DIT都可以被复制到不同的其他服务中 (slapd) 。本章节只讲述 openldap 2.4+ 的四种复制模式。 https://www.161616.top/ch05-openldap-ssl/ Thu, 19 Sep 2019 00:00:00 +0000 https://www.161616.top/ch05-openldap-ssl/ openldap合集 ch1 理解ldap - 什么是ldap ch2 理解ldap - OpenLDAP安装 ch3 理解ldap - OpenLDAP客户端命令行使用 ch4 理解ldap - OpenLDAP架构与Schema设计 ch5 理解ldap - OpenLDAP使用SSL/TLS通信安全 ch6 理解ldap - OpenLDAP中的4种复制机制 ch7 理解ldap - OpenLDAP访问控制(ACL) ch8 理解ldap - OpenLDAP备份与恢复策略 ch9 理解ldap - openldap中的一些高级配置 ch10 理解ldap - Linux系统接入OpenLDAP做认证后端 ch11 理解ldap - 使用SSSD接入OpenLDAP实现身份验证 OpenLDAP TLS/SSL 配置 对于 TLS/SSL 方向的内容不过多阐述了，这里只阐述openldap TLS/SSL 配置方向的内容 openldap提供了两种方式进行 TLS/SSL 认证 自动模式：客户端通过 ldaps://hostname/ 形式的URL访问slapd，slapd默认为636端口提供 TLS 会话 主动定义：slapd标准端口389支持 TLS/SSL ，客户端通过显式配置 TLS/SSL 也可以使用 URL格式ldap://hostname/ 进行访问，需要注意的是，在同步时如果使用 ldap:// 格式URL需要指定参数 starttls=yes 或者 starttls=critical 使用 ldaps:// 则不需要指定该参数 生成自签名证书 创建CA证书 https://www.161616.top/ch4-schema/ Sun, 01 Sep 2019 00:00:00 +0000 https://www.161616.top/ch4-schema/ openldap合集 ch1 理解ldap - 什么是ldap ch2 理解ldap - OpenLDAP安装 ch3 理解ldap - OpenLDAP客户端命令行使用 ch4 理解ldap - OpenLDAP架构与Schema设计 ch5 理解ldap - OpenLDAP使用SSL/TLS通信安全 ch6 理解ldap - OpenLDAP中的4种复制机制 ch7 理解ldap - OpenLDAP访问控制(ACL) ch8 理解ldap - OpenLDAP备份与恢复策略 ch9 理解ldap - openldap中的一些高级配置 ch10 理解ldap - Linux系统接入OpenLDAP做认证后端 ch11 理解ldap - 使用SSSD接入OpenLDAP实现身份验证 什么是schema schema又称为数据模型，是openldap中用于来指定一个条目所包含的对象类(objectClass)以及每个对象类所包含的属性值(attribute)，其中属性值又包含必要属性和可选属性。 Notes：拥有schema的数据代表该数据是结构化数据，无论他是什么格式，甚至于是一个连续的字符串 如何理解schema 不管是在学习OpenLDAP时还是学习数据库时，都会遇到一个很迷糊的Schema的概念。 在数据库中，对数据库的设计可以称之为schema。即schema约束了数据库的设计结构，并提供了整个数据库的描述。schema仅展示数据库的设计，如表字段的类型，表与表之间的关联。 在ldap中schema与database中的schema一样，如列出的schema中，这些代表了对应的ldap结构的设计。 what-is-a-schema schema overview text 1 2 3 4 5 6 7 8 9 10 11 12 olcObjectClasses: ( 0. https://www.161616.top/ch3-commandline/ Tue, 27 Aug 2019 00:00:00 +0000 https://www.161616.top/ch3-commandline/ openldap合集 ch1 理解ldap - 什么是ldap ch2 理解ldap - OpenLDAP安装 ch3 理解ldap - OpenLDAP客户端命令行使用 ch4 理解ldap - OpenLDAP架构与Schema设计 ch5 理解ldap - OpenLDAP使用SSL/TLS通信安全 ch6 理解ldap - OpenLDAP中的4种复制机制 ch7 理解ldap - OpenLDAP访问控制(ACL) ch8 理解ldap - OpenLDAP备份与恢复策略 ch9 理解ldap - openldap中的一些高级配置 ch10 理解ldap - Linux系统接入OpenLDAP做认证后端 ch11 理解ldap - 使用SSSD接入OpenLDAP实现身份验证 ldapsearch 查询api ldapsearch ldapsearch命令参数说明 语法 text 1 ldapsearch [options] filter [attributes] 参数 说 明 -W 指定密码，交互式，不需要在命令上写密码 -w 指定密码，需要命令上指定密码 -H ldapapi -D 所绑定的服务器的DN，如cn=admin,dc=etiantian,dc=org -f -f: filename. https://www.161616.top/ch2-install/ Sun, 25 Aug 2019 00:00:00 +0000 https://www.161616.top/ch2-install/ openldap合集 ch1 理解ldap - 什么是ldap ch2 理解ldap - OpenLDAP安装 ch3 理解ldap - OpenLDAP客户端命令行使用 ch4 理解ldap - OpenLDAP架构与Schema设计 ch5 理解ldap - OpenLDAP使用SSL/TLS通信安全 ch6 理解ldap - OpenLDAP中的4种复制机制 ch7 理解ldap - OpenLDAP访问控制(ACL) ch8 理解ldap - OpenLDAP备份与恢复策略 ch9 理解ldap - openldap中的一些高级配置 ch10 理解ldap - Linux系统接入OpenLDAP做认证后端 ch11 理解ldap - 使用SSSD接入OpenLDAP实现身份验证 生产服务器硬件配置需求 ldap服务对系统环境的要求不高，一般在生产场景，ldap服务应该最少是两台，这样某一台物理服务器岩机才不会因单点问题影响生产业务故障，对于硬件要求，本质上openldap使用硬件资源并不大，网上有两个帖子提出了openldap的硬件需求： 2003年openldap官网留言，我想安装一个 LDAP 服务器来验证邮件服务器的用户，目前有200个用户需要多少内存和CPU？[1] 1GHZ PIII/512MB 足以 运行于Ubuntu LXC 之上的openldap，用户150,000，sladp进程常驻内存为200-300MB，mdb数据库文件大小为377MB，10 并发平均响应时间为 9-11 毫秒 [13] 操作系统：Centos7/8 64bit。 操 作 系 统 其 它 CentOS-7.6 当前很稳定且免费的Linux版本。 网卡及IP资源 https://www.161616.top/ch8-mysql-engine/ Tue, 23 May 2017 00:00:00 +0000 https://www.161616.top/ch8-mysql-engine/ 什么是存储引擎 在经清楚什么是存储引擎之前，我们先来个比喻，我们都知道录制一个视频文件，可以转换成不同的格式如mp4 avi wmv等，而存在我们电脑的磁盘上也会存在于不同类型的文件系统中如windows里常见的ntfs fat32，存在于linux常见的ext3 ext4 xfs，但是，给我们或者用户看到实际视频内容都是一样的。直观区别是，占用系统的空间大小与清晰程度可能不一样。 那么数据库表里的数据存储在数据库里及磁盘上和上述的视频格式及存储磁盘文件系统格式特征类似，也有很多中存储方式。 但是，对于用户和应用程序来说同样一张表的数据，无论用什么引擎来存储，用户看到的数据都是一样的。不同的引擎存储，引擎功能，占用的空间大小，读取性能等可能有区别。 MySQL最常用的存储引擎为：MyISAM和InnoDB。全文索引：目前MySQL5.5版本，myisam和inondb都已经支持。 MySQL存储引擎的架构 MySQL的存储引擎是MySQL数据库的重要组成部分，MySQL常用的表的引擎为MyISAM和InnoDB两种。MySQL的每种存储引擎在MySQL里是通过插件的方式使用的，MySQL可以同时支持多种存储引擎。下面是MySQL存储引擎体系结构简图： MyISAM引擎 MyISAM引擎是MySQL关系数据库管理系统的默认存储引擎（MySQL 5.5.5以前）。这种MySQL表存储结构从旧的ISAM代码扩展出许多有用的功能。在新版本MySQL中，InnoDB引擎由于其对事务参照完整性，以及更高的并发性等优点开始逐步的取代MyISAM引擎， “InnoDB is the default storage engine as of MySQL 5.5.5。MyISAM: The MySQL storage engine that is used the most in Web,data warehousing,and other application environments.MyISAM is supported in all MySQL configurations,an is the default storage engine prior to MySQL 5.5.5。” 查看MySQL5.1数据库默认引擎 bash 1 2 3 4 5 6 7 mysql> show create table test1\G *************************** 1. https://www.161616.top/ch7-mysql-non-interact/ Mon, 22 May 2017 00:00:00 +0000 https://www.161616.top/ch7-mysql-non-interact/ 利用 mysql -e 参数查看 mysql 数据 bash 1 2 3 4 5 6 7 8 $ mysql -uroot -p111 -e 'use test;show tables;' +------------------------------+ | Tables_in_test | +------------------------------+ | 33hao_activity | | 33hao_activity_detail | | 33hao_address | +------------------------------+ 利用 mysql -e 参数查看SQL线程执行状态 bash 1 2 $ mysql -uroot -p111 -e 'show processlist;' kill 12; 查看完整的线程状态，此参数才查看慢查询语句是非常有用 解决方法： bash 1 2 3 4 root@localhost [test]>show variables like '%_timeout%'; # 设置 set global wait_timeout=60; set global interactive_timeout=60; 在配置文件里修改 text 1 2 set global wait_timeout=60; set global interactive_timeout=60; # 此参数设置后wait_timeout自动生效 其他方法 (1) PHP程序中，不适用持久链接，即 mysql_connect 而不是 pconnect（java调整连接池） https://www.161616.top/ch04-mysql-log/ Sun, 21 May 2017 00:00:00 +0000 https://www.161616.top/ch04-mysql-log/ 错误日志 error log MySQL错误日志记录MySQL服务进程mysqld在启动/关闭或运行过程中遇到的错误信息 错误日志配置 在配置文件中调整方法，当然可以在启动时加入启动参数 bash 1 2 [mysqld_safe] log-error=/data/3306/mysql_3306.err 启动MySQL命令里加入 bash 1 2 3 4 5 6 7 8 9 10 /app/mysql/bin/mysqld_safe \ --defaults-file=/data/3306/my.cnf \ --log-error=/data/3306/mysql_3306.err MariaDB> show variables like "%log_error%"; +-------------------+---------------------------+ | Variable_name | Value | +-------------------+---------------------------+ | log_error | /data/3306/mysql_3306.err | +-------------------+---------------------------+ 遇到数据库启动不了 先把日志文件备份并清空启动一下mysql服务后再查看日志文件，看报有什么错误 bash 1 2 3 InnoDB: The error means mysqld does not have the access rights to InnoDB: the directory 然后查看mysql3306目录下文件权限 普通查询日志 general query log 普通查询日志 (general query log)：记录客户端链接信息和执行的SQL语句信息。 https://www.161616.top/ch6-mysql-replication/ Sun, 21 May 2017 00:00:00 +0000 https://www.161616.top/ch6-mysql-replication/ Linux文件数据同步方案 在讲解MySQL主从复制之前，先回忆下，前面将结果的普通文件（磁盘上的文件）的同步方法。 文件级别的异机同步方案 scp/sftp/nc命令可以实现远程数据同步。 搭建ftp/http/svn/nfs服务器，然后在客户端上也可以把数据同步到服务器。 搭建samba文件共享服务，然后在客户端上也可以把数据同步到服务器。 利用rsync/csync2/union等均可以实现数据同步。 提示：union可实现双向同步，csync2可实现多机同步。 ​ 以上文件同步方式如果结合定时任务或innotify sersync等功能，可以实现定时以及实时的数据同步。 扩展思想：文件级别复制也可以利用mysql,mongodb等软件作为容器实现。 扩展思想：程序向两个服务器同时写数据，双写就是一个同步机制。 ​ 特点：简单、方便、效率和文件系统级别要差一些，但是被同步的节点可以提供访问。 软件的自身同步机制（mysql、oracle、mongdb、ttserver、redis…..），文件放到数据库，听不到从库，再把文件拿出来。 文件系统级别的异机同步方案 drbd基于文件系统同步，相当于网络RAID1，可以同步几乎任何业务数据。 mysql数据的官方推荐drbd同步数据，所有单点服务例如：NFS，MFS(DRBD)，MySQL等度可以用drbd做复制，效率很高，缺点：备机服务不可用。 数据库同步方案 自身同步机制：mysql relication，（逻辑的SQL重写）物理复制方法drbd（丛库不提供读写）。 第三方drbd MySQL主从复制概述 MySQL的主从复制方案，和上述文件及文件系统级别同步是类似的，都是数据的传输。只不过MySQL无需借助第三方工具，而是其自带的同步复制功能，另外一点，MySQL的主从复制并不是磁盘上文件直接同步，而是逻辑的binlog日志绒布到本地在应用执行的过程 MySQL主从复制是一个异步的复制过程（虽然一般情况下感觉是实时的），数据将从一个MySQL数据库（Master）复制到另一个数据库（Slave），在 mater 与 Slave之 间实现整个主从复制的过程是由三个线程参与完成的。其中有两个线程( SQL和IO )在Slave端，另外一个线程（I/O）在Master端。 要实现MySQL的主从复制，首先必须打开 Master 端的 binlog 记录功能，否则就无法实现。因为整个复制过程实际上就是Slave从Master端获取Binlog日志，然后在Slave上以相同顺序逐自获取 binlog 日志中所记录的各种SQL操作。 要打开MySQL的binlog记录功能，可能通过在MySQL的配置文件 my.cnf 中的 mysqld 模块( [mysqld] )标识后的参数部分增加 “log-bin” 参数选项来实现，具体信息如下： bash 1 2 [mysqld] log-bin = /data/3307/mysql-bin 提示：log-bin需放置在[mysqld]标识后，否则会导致配置复制不成功。 MySQL数据可支持单向、双向、链式级联等不同场景的复制。在复制过程中，一台服务器充当主服务器（Master），而一个或多个其他的服务器充当从服务器（Slave）。 复制可以使单向：M==>S，也可以是双向 M<==>M，当然也可以多M环装同步等。 如果设置了链式级联复制，那么，从（slave）服务器本身除了充当从服务器外，也会同时充当其下面从服务器的主服务器。链式级联复制类似 A==>B==>C==>D 的复制形式。 下面是MySQL各种同步架构的逻辑图。 单向主从复制逻辑图，次架构只能在Master端进行数据写入。官方给出Slave最多9，工作中不要超过5 双向主主同步逻辑图，次架构可以再Master1端或Master2端进行数据写入 线性级联单向双主同步逻辑图，此架构只能在Master1端进行数据写入 缺陷：1 ==>3 之间会存在延迟 环装级联单向多主同步逻辑图，任意一个点都可以写入数据。 https://www.161616.top/ch2-mysql-security/ Tue, 16 May 2017 00:00:00 +0000 https://www.161616.top/ch2-mysql-security/ 设置MySQL管理员账号密码 在安装MySQL数据库后，MySQL管理员的账号root密码默认为空，极不安全 启动修改丢失的MySQL单实例root密码方法 停止MySQL bash 1 /etc/init.d/mysqld stop 使用 –skip-grant-tables启动mysql，忽略授权登陆验证 bash 1 2 3 4 5 6 7 8 9 10 11 # 单实例 /app/mysql/bin/mysqld_safe --skip-grant-tables --user=mysql # 多实例 /app/mysql/bin/mysqld_safe --defaults-file=/data/3306/my.cnf --user=mysql --skip-grant-tables & # 登录时空密码 $ mysql -S /data/3306/mysql.sock ... ... Welcome to the MySQL monitor. Commands end with ; or \g. # 在启动时加 --skip-grant-tables参数，表示忽略授权 修改root密码为新密码 bash 1 2 3 4 5 6 mysql> set password=password('123'); ERROR 1290 (HY000): The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement mysql> update mysql. https://www.161616.top/ch5-mysql-charset/ Mon, 15 May 2017 00:00:00 +0000 https://www.161616.top/ch5-mysql-charset/ MySQL数据库字符集介绍 简单来说，字符集就是一套文字符号及其编码、比较规则的集合，第一个计算机字符集ASCII！ MySQL数据库字符集包括字符集(character)和校对规则(collation)两个概念。其中，字符集是用来定义MySQL数据字符串的存储方式。而校对规则则是定义比较字符串的方式。 上面命令查看已建立的test数据库语句中 CHARACTER SET latin1即为数据库字符集，而COLLATE latin1_swedish_ci为校对规则，更多内容 见mysql手册第10章。 编译MySQL时，指定字符集了，这样以后建库的时候就直接create database test; 二进制安装MySQL，并没有指定字符集，这时字符集默认latin1，此时，需要建立UTF8字符集的库，就需要指定UTF8字符集建库。 sql 1 create database test1 default character set utf8 default collate=utf8_general_ci; MySQL常见字符集介绍 在互联网环境中，使用MySQL时常用的字符集有： 常用字符集 一个汉字长度（字节） 说明 GBK 2 不是国际标准，对中文环境支持很好。 UTF8 3 中英文混合环境，建议使用此字符集，用的比较多的。 latin1 1 MySQL的默认字符集 utf8mb4 4 UTF8 Unicode，移动互联网 MySQL如何选择合适的字符集？ 如果处理各种各样的文字，发布到不同语言的国家地区，应选Unicode字符集，对MySQL来说就是utf-8（每个汉字三个字节），如果应用需处理英文，仅有少量汉字的utf-8更好。 如果只需支持中文，并且数据两很大，性能要求也高，可选GBK（定长 每个汉字占双字节，英文也占双字节），如果需大量运算，比较排序等，定长字符集更快，性能 处理移动互联网业务，可能需要使用utf8mb4字符集。 如无特别需求，选择UTF8 查看MySQL字符集 查看当前MySQL系统支持的字符集 MySQL可支持多种字符集，同一台机器，库或表的不同字段都可以指定不同的字符集。 sql 1 2 3 4 5 6 7 8 9 mysql> show character set; +----------+-------------------------+---------------------+--------+ | Charset | Description | Default collation | Maxlen | +----------+-------------------------+---------------------+--------+ | latin1 | cp1252 West European | latin1_swedish_ci | 1 | | gbk | GBK Simplified Chinese | gbk_chinese_ci | 2 | | utf8 | UTF-8 Unicode | utf8_general_ci | 3 | | utf8mb4 | UTF-8 Unicode | utf8mb4_general_ci | 4 | +----------+-------------------------+---------------------+--------+ 查看MySQL当前的字符集设置情况 https://www.161616.top/ch3-mysql-backup-and-restore/ Sun, 14 May 2017 00:00:00 +0000 https://www.161616.top/ch3-mysql-backup-and-restore/ 备份数据库的意义 运维工作到底是什么工作，到底是做什么？ 运维工作简单的概括就两件事： 一是保护公司的数据；二是网站7*24小时提供服务。 那么对数据丢失一部分和网站7*24小时提供服务那个更重要呢？ 都很重要，只是说相比哪个更为重要？这个具体要看业务个公司。例如：银行、金融行业，数据是最重要的，一条都不能丢，可能宕机停机影响就没那么大。百度搜索，腾讯qq聊天记录丢失了几万条数据，都不算啥。 对于数据来讲，数据最核心的就是数据库数据。 备份单个数据库练习多种参数的使用 MySQL数据库自带了一个很好用的备份命令，就是mysqldump，它的基本使用如下： sql 1 mysqldump -u UserName -p PassWord dbName > backName.sql 备份库 sql 1 mysqldump -S /data/3306/mysql.sock -uroot -p test>mysql.sql 检查备份结果 sql 1 2 3 4 5 6 7 8 9 10 11 12 $ egrep -v "#|\*|--|^$" ./mysql.sql DROP TABLE IF EXISTS `test1`; CREATE TABLE `test1` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `num1` varchar(20) NOT NULL, `num2` varchar(20) NOT NULL, `num3` varchar(20) NOT NULL, `num4` int(11) NOT NULL DEFAULT '0' COMMENT 'test1', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2000001 DEFAULT CHARSET=utf8; LOCK TABLES `test1` WRITE; INSERT INTO `test1` VALUES (1,'1455577','9779520','4530868',0), 注：因为导出时的格式没有加字符集，一般恢复到数据库里会正常，只是系统外查看不正常而已。另外，insert是批量插入的方式，这样在恢复时效率很高。 https://www.161616.top/ch1-mysql-deployment/ Fri, 12 May 2017 00:00:00 +0000 https://www.161616.top/ch1-mysql-deployment/ MySQL数据库简介 编程语言排名：http://www.tiobe.com/tiobe-index 数据库排名：http://db-engines.com/en/ranking MySQL数据库分类与版本升级 MySQL数据库官网为http://www.mysql.com，其发布的MySQL版本采用双授权政策，和大多数开源产品的路线一样，分别为社区版和商业版，而这两个版本又各自分四个版本依次发布，这四个版本为Alpha版、Beta版、RC版和GA版（GA正式发布版） MySQL数据库商业版和社区版的区别 在前面的内容已经阐述过了，MySQL的版本发布采用双授权政策，即分为社区版和商业版，而这两个版本又各自分四个版本依次发布：Alpha版、Beta版、RC版和GA版（GA正式发布版） Alpha版 Alpha版一般只在开发的公司内部运行，不对外公开。主要死开发者自己对产品进行测试，检查产品是否存在缺陷、错误，验证产品功能与说明书、用户手册是否一致。MySQL是属于开放源代码的开源产品，因此需要世界各地开发者、爱好者和用户参与软件的开发测试和手册编写等工作。所以会对外公布此版本的源码和产品，方便任何人可以参与开发测试工作，甚至编写与修改用户手册。 Beta版 Beta版一般是完成功能的开发和所有的测试工作时候的产品，不会存在较大的功能或性能BUG，并且邀请或提供给公户体验与测试，以便更全面地测试软件的不足之处或存在的问题。 RC版 RC版属于生产环境发布之前的一个小版本或称候选版，是根据Beta测试结果，收集到的BUG或缺陷之处等收集到信息，进行修复和完善之后的新一版本 GA版 GA版是软件产品正式发布的版本，也称生产版本的产品。一般情况下，企业生产环境都会选择GA版本的MySQL软件，用于真实的生产环境中。偶尔有个别的大型企业会追求新功能驱动而牺牲稳定性使用其他版本，但这个是个例。 MySQL四中发布版本选择说明 MySQL AB官方网站会把五种数据库版本都提供下载，主要是MySQL数据库属于开发源代码的数据库产品，鼓励全球的技术爱好者参与研发、测试、文档编写和经验分享，甚至包过产品发展规划，对于Development版本、Alpha版本和Beta版本是绝对不允许使用在任何生产环境，毕竟这是一个GA版本之前，也即生产版本发布之前的一个小版本。另外，对MySQL数据库GA版本，也是需要慎重选择，开源社区产品毕竟不是经过严格的测试工序完成的产品，是全球开源技术人员的资源完成的，会存在比商业产品稳定性弱的缺陷。更严格的选择见后文。 MySQL产品路线 MySQL产品路线变更历史背景 早起MySQL也是遵循版本号逐渐增加的方式发展的，格式例如：mysql-x.xx.xx.tar.gz，例如DBA都非常熟悉的生产场景版本：4.1.7、5.0.56等。 近几年，为了提高MySQL产品的竞争优势、以及提高性能、降低开发维护成本等原因，同时，更方便企业用户更精准的选择适合的版本产品用于自己的企业生产环境中。 MySQL在发展到5.1系列版本之后，重新规划为3条产品线 5.0.xx到5.1.xx产品线介绍 第一条产品线：5.0.xx及升级到5.1.xx的产品系列，这条产品线继续完善与改进其用户体验和性能，同时增加新功能，这条路线可以说是MySQL早起产品的延续系列，这一系列的产品发布情况及历史版本如下： MySQL 5.1是当前稳定（产品质量）发布系列。只针对漏洞修复重新发布；没有增加会影响稳定性的新功能。 MySQL 5.1:Previous stable(production-quality) release MySQL 5.0是前一稳定（产品质量）发布系列。只针对严重漏洞修复和安全修复重新发布；没有增加会影响该系列的重要功能。 MySQL 5.0:Old stable release nearing the end of the product lifecycle MySQL 4.0和3.23是旧的稳定(产品质量)发布系列。该版本不再使用，新的发布只用来修复特别严重的漏洞(以前的安全问题)。 5.4.xx开始到5.7.xx产品线系列介绍 为了更好的整合MySQL AB公司社区和第三方公司开发的新存储引擎，以及吸收新的实现算法等，从而更好的支持SMP架构，提高性能而做了大量的代码重构。版本号为从5.4.xx开始，目前发展到了5.6.x 主流：互联网公司用mysql5.5，逐步过渡到5.6。 6.0.xx-7.1.xx产品线系列介绍 第三条产品线：为了更好的推广MySQL Cluster版本，以及提高MySQL Cluster的性能和稳定性，以及功能改进和增加，以及改动mysql基础功能，使其对Cluster存储引擎提供更有效地支持与优化。版本号为6.0.xx开发，目前发展到7.1.xx MySQL数据库软件命名介绍 MySQL数据库软件的名字是由3个数字和一个后缀组成的版本号。例如，像 mysql-5.0.56.tar.gz 的版本号这样解释： 第一个数字（5）为主版本号，描述了文件格式。所有版本5发行都有相同文件格式。 第二个数字（0）为发行级别，主版本号和发行级别组合到一起便构成了发行序列号。 第三个数字（56 为在此发行系列的版本号，随每个新分发版本递增。通常你需要已经选择的发行(release)的最新版本。 每次更新后，版本字符串的最后一个数字递增。如果相对于前一个版本增加了新功能或有微小的不兼容性，字符串的第二个数字递增。如果文件格式改变，第一个数字递增。 后缀显示发现的稳定性级别。通过一系列后缀显示如何改进稳定性。可能的后缀有： alpha 表明发行包含大量未被彻底测试的新代码。已知的缺陷应该在新闻小节被记录。请参见附录D：MySQL变更史。在大多数alpha版本中也有新的命令和扩展。alpha版本也可能有主要代码更改等开发。但我们在发布前一定对其进行测试。 beta 意味着该版本功能是完整的，并且所有的新代码被测试了，没有增加重要的新特征，应该没有已知的缺陷。当alpha版本至少一个月没有出现报导的致命漏洞，并且没有计划增加导致已经实施的功能不稳定的新功能时，版本则从alpha版变为beta版。在以后的beta版、发布版或产品发布中，所有API、外部可视结构和SQL命令列均不再更改。 rc 是发布代表；是一个发行了一段时间的beta版本，看起来应该运行正常。只增加了很小的修复。(发布代表即以前所称的gamma 版) 如果没有后缀，这意味着该版本已经在很多地方运行一段时间了，而且没有非平台特定的缺陷报告。只增加了关键漏洞修复修复。这就是我们称为一个产品（稳定）或“通用”版本的东西。 https://www.161616.top/redis-security/ Wed, 23 Nov 2016 00:00:00 +0000 https://www.161616.top/redis-security/ 为Redis客户端外部设置连接密码 因为redis速度相当快，所以在一台比较好的服务器下，一个外部的用户可在一秒钟进行上万次的密码尝试，这意味着你需要指定非常非常强大的密码来防止暴力破解。 修改配置文件 bash 1 requirepass 123@1 重启服务后登录客户端提示没有验证 bash 1 2 3 $ redis-cli 127.0.0.1:6379> keys * (error) NOAUTH Authentication required. 验证成功后，可以正常操作 bash 1 2 3 4 5 127.0.0.1:6379> auth 123@1 OK 127.0.0.1:6379> keys * 1) "test-durable-1" 2) "test-durable" 命令行临时生效 在命令行设置后，redis在下次重启前，每次登录都需要验证密码 bash 1 2 3 4 5 6 127.0.0.1:6379> CONFIG set requirepass 123@1 OK 127.0.0.1:6379> quit $ redis-cli 127.0.0.1:6379> keys * (error) NOAUTH Authentication required. 注意：配置Redis复制的时候如果主数据库设置了密码，需要在从数据库的配置文件中通过masterauth参数设置主数据库的密码，以使从数据库连接主数据库时自动使用AUTH命令认证。 通过mysql命令行指定密码方式登录Redis客户端 bash 1 2 3 4 $ redis-cli -a 123@1 127. https://www.161616.top/redis-install/ Wed, 23 Nov 2016 00:00:00 +0000 https://www.161616.top/redis-install/ Remote Dictonary Server(Redis)是一个基于key-value键值对的持久化数据库存储系统。redis和大名鼎鼎的Memcached缓存服务很像,但是redis支持的数据存储类型更丰富,包括string(字符串)、list(链表)、set(集合)和zset(有序集合)、Hash等。 这些数据类型都支持push/pop,add/remove及取交集、并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached缓存服务一样，为了保证效率数据都是缓存在内存中提供服务。和memcached不同的是，redis持久化缓存服务还会周期性的把更新的数据写入到磁盘以及把修改的操作记录追加到文件里记录下来，比memcached更有优势的是，redis还支持master-slave(主从)同步,这点很类似关系型数据库MySQL。 Redis是一个开源的、使用C语言编写、３万多行代码、支持网络、可基于内存亦可久化的日志型、Key-Value数据库，并提供多种语言的API从2010年3月15日起，Redis开发工作由VMware主持。 Redis的出现，再一定程度上弥补了memcached这类key-value内存缓存服务的不足,在部分场合可以对关系数据库起到很好的补充作用.redis提供了Python, Ruby, Erlang, PHP客户端，使用很方便。redis官方文档如下：http://www.redis.io/documentation Redis的优点 与memcached不用，redis可以持久化存储数据。 性能很高：Redis能支持超过10w/秒的读写频率。 丰富的数据类型：redis支持二进制的Strings, Lists, Hashes, Sets及sorted sets等数据类型操作。 原子：Redis的所有操作都是原子性的,同时Redis还支持对几个操作全并后的原子性执行。 丰富的特性：Redis还支持publish/subscribe(发布/订阅)，通知，key过期等等特性。 redis支持异步主从复制。 Redis的应用场景 传统的MySQL+Memcached的网站架构遇到的问题： MySQL数据库实际上是适合进行海量数据存储的,加上通过Memcached将热点数据 存放到到内存cache里,达到加速数据访问的目的,绝大部分公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的增长,很多问题就会暴漏出来： 需要不断的对MySQL进行拆库拆表Memcached也需不断跟着扩容,扩容和维护工作占据大量开发运维时间。 Memcached与MySQL数据库数据一致性问题是个老大难。 Memcached数据命中率低或down机,会导致大量访问直接穿透到数据库,导致MySQL无法支撑访问。 跨机房cache同步一致性问题。 redis在微博中的应用 计数器：微博（评论、转发、阅读、赞等） 用户（粉丝、关注、收藏、双向关注等） redis在短信中的应用 发送短信后存入redis中60秒过期。 redis的最佳应用场景 Redis最佳试用场景是全部数据in-memory。 Redis更多场景是作为Memcached的替代品来使用。 当需要除key/value之外的更多数据类型支持时,使用Redis更合适。 数据比较重要，对数据一致性有一定要求的业务。 当存储的数据不能被剔除时,使用Redis更合适。 更多 Redis作者谈Redis应用场景 http://blog.nosglfan.com/html/2235.html 使用redis bitmap进行活跃用户统计 http://blog.nosqlfun.com/html/3501.html 计数、cache服务、展示最近、最热、点击率最高、活跃度最高等等条件的top list、用户最近访问记录表、relation list/Message Queue、粉丝列表 Key-Value Store更加注重对海量数据存取的性能、分布式、扩展性支持上，并不需要传统关系数据库的一些特征。例如：Schema事务、完整SQL查询支持等等，因此在布式环境下的性能相对于传统的关系数据库有较大的提升。 redis的生产经验教训 要进行Master-slave主从同步配置，在出现服务故障时可以切换。 在master禁用数据据持久化只需在slave上配置数据持久化。 物理内存+虚拟内存不足，这个时候dump一直死着，时间久了机器挂掉。这个情就是灾难。 当Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了，就开始做swap，内存碎片大！ 当达到最大内存时，会清空带有过期时间的如 redis与DB同步写的问题，先写DB，后写redis，因为写内存基本上没有问题。 业务场景 提高了DB的可扩展性,只需要将新加的数据放到新加的服务器上就可以了。 提高了DB的可用性,只影响到需要访问的shard服务器上的数据的用户。 提高了DB的可维护性,对系统的升级和配里可以按shard一个个来搞,对服务产生的影响小。 小的数据库存的查询压力小,查询更快,性能更好。 使用过程中的一些经验与教训,做个小结： 要进行Master-slave配置,出现服务故障时可以支持切换。 在master侧禁用数据持久化,只需在slave上配置数据持久化。 物理内存+虚拟内存不足时,这个时候dump已知死着,时间久了机器挂掉。这个情况就是灾难。 当Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了,就开始做swap,内存碎片大。 当达到最大内存时,会清空带有过期时间的key,即使key未到过期时间。 redis与DB同步写的问题,先写DB,后写redis,因为写内存基本上没有问题。 安装配置Redis 下载安装Redis redis官方网站：www. https://www.161616.top/redis-subscribe-and-transaction/ Wed, 23 Nov 2016 00:00:00 +0000 https://www.161616.top/redis-subscribe-and-transaction/ 发布与订阅 Publish/Subscribe 发布订阅(pub/sub)是一种消息通信模式，主要的目的是解耦消息发布者和消息订阅者之间的藕合，这点和设计模式中的观察者模式比较相似。pub/sub不仅仅解决发布者和订阅者直接代码级别耦合也解决两者在物理部署上的耦合。Redis作为一个pub/sub的server,在订阅者和发布者之间起到了消息路由的功能。订阅者可以通过subscribe和psubscribe命令向Redis server订阅自己感兴趣的消息类型，Redis将消息类型称为通道(channel)。当发布者通过publish命令向Redis server发送特定类型的消息时。订阅该消息类型的全部client 都会收到此消息。这里消息的传递是多对多的。一个client可以订阅多个channel,也可以向多个channel发送消息。 Redis支持这样一种特性，你可以将数据推到某个信息管道中，然后其它人可以通过订阅这些管道来获取推送过来的信息。 用一个客户端订阅频道 bash 1 2 3 4 5 6 psubscribe new #### 1.批量订阅 127.0.0.1:6379> publish news news-test (integer) 1 127.0.0.1:6379> publish video video-test (integer) 1 此时可以见到接受的信息 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 127.0.0.1:6379> psubscribe news video Reading messages... (press Ctrl-C to quit) 1) "psubscribe" 2) "news" 3) (integer) 1 1) "psubscribe" 2) "video" 3) (integer) 2 1) "pmessage" 2) "news" 3) "news" 4) "news-test" 1) "pmessage" 2) "video" 3) "video" 4) "video-test" 数据过期设置及机制 Redis key的过期机制 Redis对过期键采用了lazy expiration：在访间key的时候判定key是否过期，如果过期，则进行过期处理（过期的key没有被访间可能不会被删除）。其次，每秒对volatile keys进行抽样测试，如果有过期键，那么对所有过期key进行处理。 https://www.161616.top/redis-persist/ Wed, 23 Nov 2016 00:00:00 +0000 https://www.161616.top/redis-persist/ Redis的所有数据都存储在内存中，但是他也提供对这些数据的持久化。 Redis是一个支持持久化的内存数据库，Redis需要经常将内存中的数据同步到磁盘来保证持久化。Redis支持四种持久化方式，一种是 Snapshotting(快照)也是默认方式 ，另一种是 Append-only file(aof)的方式 。 RDB持久化方式 Snapshotting方式是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化。例如可以配置redis在n秒内如果超过m个key被修改就自动做快照。 实现机制 Redis调用fork子进程。 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的实时复制机制(copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程地址空间内的数据是fork时刻整个数据库的一个快照。 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。client也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有client的请求，这种方式会阻塞所有clien:请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是完整写入到磁盘一次并不是增量的只同步变更数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘IO操作，可能会严重影响性能。 缺点： 快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用aof持久化方式。 相关配置 bash 1 2 3 4 5 6 7 8 save 900 1 #←900秒内至少有1个key被改变 save 300 10 #←300秒内至少有10个key被改变 save 60 10000 #←60秒内至少有10000个key被改变 stop-writes-on-bgsave-error yes #←后台存储错误后停止写。如：磁盘空间不足 rdbcompression yes #←使用LZF压缩rdb文件 rdbchecksum yes #←存储和加载rdb文件时校验 dbfilename dump.rdb #←存储rdb文件名 dir /app/redis/db/ #←rdb文件路径 持久化测试 bash 1 2 3 4 5 11512:M 22 Apr 01:04:47.028 * 5 changes in 60 seconds. https://www.161616.top/redis-datatype/ Wed, 23 Nov 2016 00:00:00 +0000 https://www.161616.top/redis-datatype/ key/value介绍 Redis key值是二进制安全的，这意味着可以用任何二进制序列作为key值，从形如“0foo”的简单字符串到一个JPG文件的内容都可以。空字符串也是有效key值。 关于key的几条规则： 太长的键值，例如1024字节的键值，不仅因为消耗内存，而且在数据中查找这类键值的计算成本很高。 太短的键值，如果你要用 u:1000:pwd来代替user:1000:password，这没有什么问题，但后者更易阅读，并且由此增加的空间消耗相对于key object和value object本身来说很小.当然，没人阻止您一定要用更短的键值节省一丁点空间。 最好坚持一种模式;。例如：object-type:id:field就是个不错的注意，像这样user:1000:password。我喜欢对多单词的字段名中加上一个点，就像这样：comment.1234.renlv_to key建议：object-type:id:field 长度10-20 value建议：string不要超过2K set sortedset元素不要超过5000 bash 1 2 3 4 $ redis-cli set user_list:user_id:5 zhangsan OK $ redis-cli get user_list:user_id:5 "zhangsan" 通用操作 找到全部给定模式的匹配到的key bash 1 2 3 4 5 6 7 127.0.0.1:6379> keys * #<==打印全部key 1) "name" 2) "site" 127.0.0.1:6379> keys na[ma]e #<==返回正则匹配到的key 1) "name" 127.0.0.1:6379> keys nam? 1) "name" randomkey返回随机key bash 1 2 3 4 127.0.0.1:6379> randomkey "name" 127.0.0.1:6379> randomkey "site" exists检查key是否存在 bash 1 2 3 4 127. https://www.161616.top/redis-replication/ Wed, 23 Nov 2016 00:00:00 +0000 https://www.161616.top/redis-replication/ Replication的工作原理 设置一个Slave，无论是第一次还是重连到Master，它都会发出一个sync命令。当Master收到sync命令之后，会做两件事： Master执行BGSAVE，即在后台保存数据到磁盘（rdb快照文件）。 Master同时将新收到的写入和修改数据集的命令存入缓冲区（非查询类）。 当Master在后台把数据保存到快照文件完成之后，把这个快照传送给Slave，而Slave则把内存清空后，加载该文件到内存中。而Master也会把此前收集到缓冲区中的命令，通过Reids命令协议形式转发给Slave，Slave执行这些命令，实现和Master的同步。Master/Slave此后会不断通过异步方式进行命令的同步。 注：在redis2.8之前，主从之间一旦发生重连都会引发全量同步操作。但在2.8之后版本，也可能是部分同步操作。 部分复制 2.8后，当主从之间的连接断开之后，他们之间可以采用持续复制处理方式代替采用全量同步。Master端为复制流维护一个内存缓冲区（in-memory backlog），记录最近发送的复制流命令；同时，Master和Slave之间都维护一个复制偏移量(replication offset)和当前Master服务器ID（Master run id）。当网络断开，Slave尝试重连时： 如果MasterID相同（即仍是断网前的Master服务器），并且从断开时到当前时刻的历史命令依然在Master的内存缓冲区中存在，则Master会将缺失的这段时间的所有命令发送给Slave执行，然后复制工作就可以继续执行了 否则，依然需要全量复制操作。 Redis 2.8 的这个部分重同步特性会用到一个新增的PSYNC内部命令， 而 Redis 2.8以前的旧版本只有SYNC命令，不过，只要从服务器是Redis 2.8或以上的版本，它就会根据主服务器的版本来决定到底是使用 PSYNC还是SYNC。 如果主服务器是 Redis 2.8 或以上版本，那么从服务器使用 PSYNC 命令来进行同步。 如果主服务器是 Redis 2.8 之前的版本，那么从服务器使用 SYNC 命令来进行同步。 redis主从同步特点 一个Master可以有多个Slave。 Redis使用异步复制。从2.8开始，Slave会周期性（每秒一次）发起一个ack确认复制流（replication stream）被处理进度； 不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器， 多个从服务器之间可以构成一个图状结构； 复制在Master端是非阻塞模式的，这意味着即便是多个Slave执行首次同步时，Master依然可以提供查询服务； 复制在Slave端也是非阻塞模式的：如果你在redis.conf做了设置，Slave在执行首次同步的时候仍可以使用旧数据集提供查询；你也可以配置为当Master与Slave失去联系时，让Slave返回客户端一个错误提示； 当Slave要删掉旧的数据集，并重新加载新版数据时，Slave会阻塞连接请求（一般发生在与Master断开重连后的恢复阶段）； 复制功能可以单纯地用于数据冗余（data redundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）： 比如说， 繁重的 SORT 命令可以交给附属节点去运行。 可以通过修改Master端的redis.config来避免在Master端执行持久化操作（Save），由Slave端来执行持久化。 redis replication配置文件详解 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 slaveof [masterip] [masterport] #←该redis为slave ip和port是master的ip和port masterauth <master-password> #←如果master设置了安全密码，此处为master的安全密码 slave-serve-stale-data yes#←当slave丢失master或同步正在进行时，如果发生对slave的服务请求： slave-serve-stale-data no #←slave返回client错误:"SYNC with master in progress" slave-serve-stale-data yes #←slave依然正常提供服务 slave-read-only yes #←设置slave不可以写数据，只能用于同步 repl-ping-slave-period 10 #←发送ping到master的时间间隔 repl-timeout 60 #←IO超时时间 repl-backlog-size 1mb #←backlog的大小，当从库连接不到主库时，backlog的队列能放多少 repl-backlog-ttl 3600 #←backlog的生命周期 min-slaves-max-lag 10 #←延迟小于min-slaves-max-lag秒的slave才认为是健康的slave # 当master不可用,Sentinel会根据slave的优先级选举一个master。 # 最低的优先级的slave,当选master. https://www.161616.top/memcached/ Wed, 28 Sep 2016 00:00:00 +0000 https://www.161616.top/memcached/ 1 Memcached介绍及常见同类软件对比 1.1 Memcached是什么？ Memcached是一个开源的、支持高性能、高并发的分布式缓存系统，由C语言编写，总共2000多行代码。从软件名称上看，前3个字符的单词Mem就是内存的意思，接下来的后面5个字符的单词Cache就是缓存的意思，最后一个字符d是daemon的意思，代表是服务端守护进程模式服务。 Memcached服务分为服务端和客户端两部分，其中，服务端软件的名字形如 Memcached-1.4.24.tat.gz，客户端软件的名字形如 Memcache-2.25.tar.gz Memcached软件诞生于2003年，最初由LiveJournal的BradFitzpatrick开发完成。Memcached是整个项目的名称，而Memcached是服务器端的主程序名，因其协议简单，使用部署方便、且支持高并发而被互联网企业广泛使用，知道现在仍然被广泛应用。官方网址：http://memcached.org 1.2 Memcached的作用 传统场景，多数Web应用都将数据保存到关系型数据库中（例如MySQL），Web服务器从中读取数据并在浏览器中显示。但随着数据量的增大、访问的集中，关系型数据库的负担就会加重、响应缓慢、导致网站打开延迟等问题，影响用户体验。 这时就需要Memcached软件出马了。使用Memcached的主要目的是，通过在自身内存中缓存关系型数据库的查询结果，减少数据库自身被访问的次数，以提高动态web应用的速度、提高网站架构的并发能力和可扩展性。 Memcached服务的运行原理是通过在实现规划好的系统内存空间中临时缓存数据库的各类数据，以达到减少前端业务服务对数据库的直接高并发访问，从而达到提升大规模网站急群众动态服务的并发访问能力。 生产场景的Memcached服务一般被用来保存网站中经常被读取的对象或数据，就像我们的客户端浏览器也会把经常访问的网页缓存起来一样，通过内存缓存来存取对象或数据要比磁盘存取快很多，因为磁盘是机械的，因此，在当今的IT企业中，Memcached的应用范围很广泛 1.3 互联网常见内存服务软件 下表为互联网企业场景常见内存缓存服务软件相关对比信息： 软件 类型 主要作用 缓存的数据 Memcached 纯内存型 常用于缓存网站后端的各类数据，例如数据库中的数据 主要缓存用户重复请求的动态内容，blog的博文BBS的帖子等内容用户的Session会话信息 Redis/Mongodb/memcachedb 可持久化存储，即使用内存也会使用磁盘存储 1. 缓存后端数据库的查询数据 2.作为关系数据库的重要补充 1.作为缓存：主要缓存用户重复请求的动态内容：例如BLOG的博文、BBS的帖子等内容。2.作为数据库的有效补充：例如：好友关注、粉丝统计、业务统计等功能可以用持久化存储。 Squid/Nginx 内存或内存加磁盘缓存 主要用于缓存web前端的服务内容 主要用于静态数据缓存，例如：图片，附件（压缩包），js,css,html等，此部分功能大多数企业会选择专业的CDN公司如：蓝讯、网宿。 2 Memcached常见用途工作流程 Memcached是一种内存缓存软件，在工作中经常用来缓存数据库的查询数据，数据被缓存在事先预分配的Memcached管理的内存中，可以通过API或命令的方式存取内存中缓存的这些数据，Memcached服务内存中缓存的数据就像一张巨大的HASH表，每条数据都是以key-value对的形式存在。 2.1 网站读取Memcached数据时的工作流程 Memcached用来缓存查询到的数据库中的数据，逻辑上，当程序访问后端数据库获取数据时会先优先访问Memcached缓存，如果缓存中有数据就直接返回给客户端用户，如果没有数据（没有命中）程序再去读取后端的数据库的数据，读取到需要的数据后，把数据返回给客户端，同时还会把读取到的数据库缓存到Memcached内存中，这样客户端用户再请求相同数据就会直接读取Memcached缓存的数据，这样就大大减轻了后端数据库的压力，并提高了整个网站的响应速断，提升了用户体验。 图2-1展示了Memcached缓存系统和后端数据库系统的协作流程 上图，使用Memcached缓存查询数据来减少数据库压力的具体工作流程如下： web程序首先检查客户端请求的数据是否在Memcached缓存中存在，如果存在，直接把请求的数据返回给客户端，此时不在请求后端数据库。 如果请求的数据在Memcached缓存中不存在，则程序会请求数据库服务，把数据库中取到的数据返回给客户端，此时不再请求后端数据库。 2.2 网站更新Memcached数据时工作流程 当程序更新或者删除数据时，会首先处理后端数据库中的数据。 程序处理后端数据库中的数据的同时，也会通知Memcached中的对应旧数据失效，从而保证Memcached中缓存的数据始终和数据库中的户数一直，这个数据一致性非常重要，也是大型网站分布式缓存集群的最头痛的问题所在。 如果是在高并发读写场合，除了要程序通知Memcached过期的缓存失效外，还可能会通过相关机制，例如在数据库上部署相关程序（例如：在数据库中设置触发器使用UDFs），实现当数据库有更新就会把数据更新到Memcached服务中，使得客户端在访问新数据前，预先把更新过的数据库数据复制到Memcached中缓存起来，这样可以减少第一次查询数据库带来的访问压力，提升Memcached中缓存的命中率，甚至sina门户还会把持久化存储redis做成MySQL数据库的从库，实现真正的主从复制。 Memcached网站作为缓存应用更新数据流程图见下图1-2 Memcached服务作为缓存应用通过相关软件更新数据见图2-2 3 Memcached在企业中的应用场景 3.1 作为数据库查询数据缓存 3.1.1 完整数据缓存 例如电商的商品分类功能不会经常变动，就可以实现放到Memcached里，然后再对外提供数据访问。这个过程被称之为“数据预热”。 此时秩序读取缓存无需读取数据库就能读到Memcached缓存里的所有商品分类数据了，所以数据库的访问压力就会大大降低了。 为什么商品分类数据可以实现放在缓存里呢？ 因为，商品分类几乎都是由内部人员管理的，如果需要更新数据，更新数据库后，就可以把数据同时更新到Memcached里。 如果把商品分类数据做成静态化文件，然后通过在前段WEB缓存或者使用CDN加速效果更好。 3.1.2 热点数据缓存 热点数据缓存一般是用于由用户更新的商品，例如淘宝的卖家，当卖家新增商品后，网站程序就会把商品写入后端数据库，同时把这部分数据，放入Memcached内存中，下一次访问这个商品的请求就直接从Memcached内存中取走了。这种方法用来缓存网站热点的数据，即利用Memcached缓存经常被访问的数据。 特别提示：这个过程可以通过程序实现，也可以在数据库上安装软件进行设置，直接由数据库把内容更新到Memcached中，相当于Memcached是MySQL的丛库一样。 淘宝、京东、小米等电商双11秒杀抢购场景： 如果碰到电商双11秒杀高并发的业务场景，必须要实现预热各种缓存，包括前端的web缓存和后端的数据缓存。 https://www.161616.top/consistent-hash/ Wed, 28 Sep 2016 00:00:00 +0000 https://www.161616.top/consistent-hash/ Memcache应用场景 基本场景 比如有 N 台 cache 服务器（后面简称 cache），那么如何将一个对象 object 映射到 N 个 cache 上呢，你很可能会采用类似下面的通用方法计算 object 的 hash 值，然后均匀的映射到到N个cache; hash(object)%N 如下图： 这时，一切都运行正常，再考虑如下的两种情况： 一个 cache服务器m down掉了（在实际应用中必须要考虑这种情况），这样所有映射到cache m的对象都会失效，怎么办，需要把cache m从cache 中移除，这时候 cache 是 $N-1$ 台，映射公式变成了 hash(object)%(N-1) 。此时数据 $3%3-1=3%2=1$ 此时，3应该在S3上，但是由于S3down机导致到S1去取，这时会未命中。如下图 由于访问加重，需要添加 cache ，这时候 cache 是 $N+1$ 台，映射公式变成了 hash(object)%(N+1) 。1和2意味着突然之间几乎所有的 cache 都失效了。对于服务器而言，这是一场灾难，洪水般的访问都会直接冲向后台服务器。$\frac{N-1} { N\times (N-1)}$ 即： 有N台服务器，变为 $N-1$ 台，即每 $N \times (N-1)$个数中，求余相同的只有 N-1 个。命中率为：$\frac{1}{3}$ 再来考虑第三个问题，由于硬件能力越来越强，你可能想让后面添加的节点多做点活，显然上面的 hash 算法也做不到。 有什么方法可以改变这个状况呢，这就是 consistent hashing… 但现在一致性hash算法在分布式系统中也得到了广泛应用，研究过memcached缓存数据库的人都知道，memcached服务器端本身不提供分布式cache的一致性，而是由客户端来提供，具体在计算一致性hash时采用如下步骤： 首先求出memcached服务器（节点）的哈希值，并将其配置到 0～232 的圆（continuum）上。 然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。 然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过232仍然找不到服务器，就会保存到第一台memcached服务器上。