1.搜索镜像
|
1 |
docker search redis |
2.拉取镜像
|
1 |
docker pull redis |
3.创建Redis容器并设置密码
|
1 2 |
docker run --name redis -d --restart=always --privileged=true -p 6379:6379 redis --requirepass 123456 #前边是宿主机端口 后面是docker使用的端口 |
4.备注 为现有的redis创建密码或修改密码的方法： 1.进入redis的容器 docker exec -it 容器ID bash 2.进入redis目录 /usr/local/bin 3.运行命令：redis-cli 4.查看现有的redis密码：config get requirepass 5.设置redis密码config set requirepass ****（****为你要设置的密码） 6.若出现(error) NOAUTH Authentication required.错误，则使用 auth 密码 来认证密码 from:https://www.cnblogs.com/zhangzimo/p/12753563.html
View Details开发环境最近遇到了"MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk"的问题，服务出现了问题，一看日志是Redis在报这个错误。 查了查网上的资料，解决方案基本都是修改Redis的配置文件，将 stop-writes-on-bgsave-error yes修改为 stop-writes-on-bgsave-error no 这是一个暂时性的解决方法。看了看stackoverflow上的回答，最高赞回答是这样的，如下图： 大概意思是：这是一个快速应急方法，如果你担心你的数据，那就首先检查下bgsave方法为什么会失败。bgsave方法是干什么的呢？咱来看下面这张图： bgsave方法为什么会失败呢？咱们看看大佬的回答 大概意思是（翻译不到位的地方，还请见谅，英文比较菜）：在BGSAVE时，Redis会fork一个子进程，把数据保存到硬盘上。你可以通过查看日志来获取BGSAVE失败的原因（Linux系统里Redis日志文件通常是在/var/log/redis/redis-server.log），大多数时候BGSAVE失败的原因是fork进程分配不到内存。更多时候，fork进程分配不到内存是因为跟操作系统的优化相冲突，即使操作系统有足够的内存。（下面一大段就不翻译了，意思是可以Redis官网找到相应的解释，文末会把相关文章链接都缀上）。当然大神也给出了解决方案 Linux系统中，修改/etc/sysctl.conf文件，添加配置： vm.overcommit_memory=1 执行命令，使其生效 sudo sysctl -p /etc/sysctl.conf 参考文章链接： stackoverflow的回答链接 BGSAVE命令解释 redis官网的faq from:https://blog.csdn.net/u014071875/article/details/103715183
View Details今天重启游戏服务器在连接redis数据库时突然报错：MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error. 究其原因是因为强制把redis快照关闭了导致不能持久化的问题，在网上查了一些相关解决方案，通过stop-writes-on-bgsave-error值设置为no即可避免这种问题。 有两种修改方法，一种是通过redis命令行修改，另一种是直接修改redis.conf配置文件 命令行修改方式示例： 127.0.0.1:6379> config set stop-writes-on-bgsave-error no 修改redis.conf文件：vi打开redis-server配置的redis.conf文件，然后使用快捷匹配模式：/stop-writes-on-bgsave-error定位到stop-writes-on-bgsave-error字符串所在位置，接着把后面的yes设置为no即可。 from:https://blog.csdn.net/qq_31766907/article/details/78715935
View Details具体错误： 使用mysql创建、调用存储过程，函数以及触发器的时候会有错误符号为1418错误。 [Err] 1418 – This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) 查阅相关资料，意思是说binlog启用时，创建的函数没有声明类型，因为binlog在主从复制需要知道这个函数创建语句是什么类型，否则同步数据会有不一致现象。 mysql开启了bin-log, 我们就必须指定我们的函数是否是哪种类型： 1 DETERMINISTIC 不确定的 2 NO SQL 没有SQl语句，当然也不会修改数据 3 READS SQL DATA 只是读取数据，当然也不会修改数据 4 MODIFIES SQL DATA 要修改数据 5 CONTAINS SQL 包含了SQL语句 为了解决这个问题，MySQL强制要求： 在主服务器上，除非子程序被声明为确定性的或者不更改数据，否则创建或者替换子程序将被拒绝。这意味着当创建一个子程序的时候，必须要么声明它是确定性的，要么它不改变数据。 声明方式有两种： 第一种:声明是否是确定性的 DETERMINISTIC和NOT DETERMINISTIC指出一个子程序是否对给定的输入总是产生同样的结果。 如果没有给定任一特征，默认是NOT DETERMINISTIC，所以必须明确指定DETERMINISTIC来声明一个子程序是确定性的。 这里要说明的是:使用NOW() 函数（或它的同义）或者RAND() 函数不会使一个子程序变成非确定性的。对NOW()而言，二进制日志包括时间戳并会被正确的执行。RAND()只要在一个子程序内被调用一次也可以被正确的复制。所以，可以认为时间戳和随机数种子是子程序的确定性输入，它们在主服务器和从服务器上是一样的。 第二种:声明是否会改变数据 CONTAINS SQL, NO SQL, READS SQL DATA, MODIFIES SQL用来指出子程序是读还是写数据的。 无论NO SQL还是READS SQL DATA都指出，子程序没有改变数据，但是必须明确地指定其中一个，因为如果任何指定，默认的指定是CONTAINS SQL。 默认情况下，如果允许CREATE PROCEDURE 或CREATE […]
View Details|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
DELIMITER // CREATE DEFINER=`root`@`localhost` PROCEDURE `p_Uppercase`(IN `dbname` varchar(200)) BEGIN DECLARE done INT DEFAULT 0; DECLARE oldname VARCHAR(200); DECLARE cur CURSOR FOR SELECT table_name FROM information_schema.TABLES WHERE table_schema = dbname; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1; OPEN cur; REPEAT FETCH cur INTO oldname; SET @newname = UPPER(oldname); SET @isNotSame = @newname <> BINARY oldname; IF NOT done && @isNotSame THEN SET @SQL = CONCAT('rename table `',oldname,'` to `', LOWER(@newname), '_tmp` '); PREPARE tmpstmt FROM @SQL; EXECUTE tmpstmt; SET @SQL = CONCAT('rename table `',LOWER(@newname),'_tmp` to `',@newname, '`'); PREPARE tmpstmt FROM @SQL; EXECUTE tmpstmt; DEALLOCATE PREPARE tmpstmt; END IF; UNTIL done END REPEAT; CLOSE cur; END// DELIMITER ; |
View Details
SQL(Structure Query Language)语言是数据库的核心语言。 SQL的发展是从1974年开始的，其发展过程如下： 1974年—--由Boyce和Chamberlin提出，当时称SEQUEL。 1976年—--IBM公司的Sanjase研究所在研制RDBMS SYSTEM R 时改为SQL。 1979年—--ORACLE公司发表第一个基于SQL的商业化RDBMS产品。 1982年—--IBM公司出版第一个RDBMS语言SQL/DS。 1985年—--IBM公司出版第一个RDBMS语言DB2。 1986年—--美国国家标准化组织ANSI宣布SQL作为数据库工业标准。 SQL是一个标准的数据库语言，是面向集合的描述性非过程化语言。 它功能强，效率高，简单易学易维护（迄今为止，我还没见过比它还好 学的语言）。然而SQL语言由于以上优点，同时也出现了这样一个问题： 它是非过程性语言，即大多数语句都是独立执行的，与上下文无关，而 绝大部分应用都是一个完整的过程，显然用SQL完全实现这些功能是很困 难的。所以大多数数据库公司为了解决此问题，作了如下两方面的工作： (1)扩充SQL，在SQL中引入过程性结构；(2)把SQL嵌入到高级语言中， 以便一起完成一个完整的应用。 二. SQL语言的分类 SQL语言共分为四大类：数据查询语言DQL，数据操纵语言DML，数据定义语言DDL，数据控制语言DCL。 1. 数据查询语言DQL 数据查询语言DQL基本结构是由SELECT子句，FROM子句，WHERE 子句组成的查询块： SELECT <字段名表> FROM <表或视图名> WHERE <查询条件> 2 .数据操纵语言DML 数据操纵语言DML主要有三种形式： 1) 插入：INSERT 2) 更新：UPDATE 3) 删除：DELETE 3. 数据定义语言DDL 数据定义语言DDL用来创建数据库中的各种对象—--表、视图、 索引、同义词、聚簇等如： CREATE TABLE/VIEW/INDEX/SYN/CLUSTER | | | | | 表 视图 索引 同义词 簇 DDL操作是隐性提交的！不能rollback 4. 数据控制语言DCL 数据控制语言DCL用来授予或回收访问数据库的某种特权，并控制 数据库操纵事务发生的时间及效果，对数据库实行监视等。如： 1) GRANT：授权。 2) ROLLBACK [WORK] TO [SAVEPOINT]：回退到某一点。 回滚—ROLLBACK 回滚命令使数据库状态回到上次最后提交的状态。其格式为： SQL>ROLLBACK; 3) COMMIT [WORK]：提交。 在数据库的插入、删除和修改操作时，只有当事务在提交到数据 库时才算完成。在事务提交前，只有操作数据库的这个人才能有权看 […]
View Details锁是计算机协调多个进程或线程并发访问某一资源的机制。锁保证数据并发访问的一致性、有效性；锁冲突也是影响数据库并发访问性能的一个重要因素。锁是Mysql在服务器层和存储引擎层的的并发控制。 加锁是消耗资源的，锁的各种操作，包括获得锁、检测锁是否是否已解除、释放锁等。 锁机制 共享锁与排他锁 共享锁（读锁）：其他事务可以读，但不能写。 排他锁（写锁） ：其他事务不能读取，也不能写。 粒度锁 MySQL 不同的存储引擎支持不同的锁机制，所有的存储引擎都以自己的方式显现了锁机制，服务器层完全不了解存储引擎中的锁实现： MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking） BDB 存储引擎采用的是页面锁（page-level locking），但也支持表级锁 InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 默认情况下，表锁和行锁都是自动获得的， 不需要额外的命令。 但是在有的情况下， 用户需要明确地进行锁表或者进行事务的控制， 以便确保整个事务的完整性，这样就需要使用事务控制和锁定语句来完成。 不同粒度锁的比较： 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 这些存储引擎通过总是一次性同时获取所有需要的锁以及总是按相同的顺序获取表锁来避免死锁。 表级锁更适合于以查询为主，并发用户少，只有少量按索引条件更新数据的应用，如Web 应用 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 最大程度的支持并发，同时也带来了最大的锁开销。 在 InnoDB 中，除单个 SQL 组成的事务外， 锁是逐步获得的，这就决定了在 InnoDB 中发生死锁是可能的。 行级锁只在存储引擎层实现，而Mysql服务器层没有实现。 行级锁更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。 MyISAM 表锁 MyISAM表级锁模式： 表共享读锁 （Table Read Lock）：不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求； 表独占写锁 （Table Write Lock）：会阻塞其他用户对同一表的读和写操作； MyISAM 表的读操作与写操作之间，以及写操作之间是串行的。当一个线程获得对一个表的写锁后， 只有持有锁的线程可以对表进行更新操作。 其他线程的读、 写操作都会等待，直到锁被释放为止。 默认情况下，写锁比读锁具有更高的优先级：当一个锁释放时，这个锁会优先给写锁队列中等候的获取锁请求，然后再给读锁队列中等候的获取锁请求。 （This ensures that updates to a table are not “starved” even when there is heavy SELECT activity for the table. However, if there are many updates for […]
View DetailsALTER DATABASE 数据库 CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; ALTER TABLE 表 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; 数据库连接字符串加上：charset=utf8mb4
View Details最近遇到一个mysql生产问题，一直报:报错误 0x80004005 Incorrect string value: '\xF0\xA0\x83\x8A2\xE4…' for column 经过排查原来数据库和表都是默认utf8编码，老司机都知道，mysql中的utf8编码有一个大坑，不是真正的utf8。当遇到特殊字符就会插入失败报下面的错误： MySql.Data.MySqlClient.MySqlException (0x80004005): Incorrect string value: '\xF0\xA0\x83\x8A2\xE4…' for column 使用环境： 1、asp.net core 2.2 2、dapper 3、mysql8 通过下面步骤完美解决： 一、首先查看当前数据库编码 1 show variables like 'character%' 最后必须要达到下面的设置： 二、更改数据库编码 1 ALTER DATABASE 数据库名称 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; 三、更改所有表和列编码 先生成所有表的更改语句，这样可以批量mysql所有表和列编码为utf8mb4 1 2 3 4 5 6 7 8 9 10 SELECT CONCAT( 'ALTER TABLE ', TABLE_NAME, ' CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;' ) FROM information_schema.TABLES WHERE TABLE_SCHEMA =’数据库名称'; 把上面查询结果导出，执行就行了。 四、更改数据库配置 数据库配置my.ini或my.cnf，你的配置可能不叫这个句子。 修改为如下配置： 1 2 3 4 5 6 7 [client] default-character-set=utf8mb4 [mysql] default-character-set=utf8mb4 [mysqld] collation-server = utf8mb4_general_ci character-set-server = utf8mb4 更改之后重启mysql 五、修改数据库连接 经过上面4步骤，以为就万事大吉了。 注意：一定要修改程序的数据库连接，不然照样报错。 如下： 1 Host=localhost;Port=3306;Database=lanhu;Uid=www.lanhusoft.com;pwd=lanhusoft;Charset=utf8mb4; 之前我们写成utf8都不行，一定要写成utf8mb4 from:https://lesg.cn/Article-53016.html
View Details