搜索到
15
篇与
数据库
的结果
-
关于MYSQL中BINLOG_FORMAT的三种模式 MYSQL中BINLOG_FORMAT的三种模式mysql复制主要有三种方式：基于SQL语句的复制(statement-based replication, SBR)，基于行的复制(row-based replication, RBR)，混合模式复制(mixed-based replication, MBR)。对应的，binlog的格式也有三种：STATEMENT，ROW，MIXED。① STATEMENT模式（SBR）每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)② ROW模式（RBR）不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨。③ MIXED模式（MBR）以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。binlog复制配置在mysql的配置文件my.cnf中，可以通过一下选项配置binglog相关代码如下 复制代码binlog_format = MIXED //binlog日志格式，mysql默认采用statement，建议使用mixedlog-bin = /data/mysql/mysql-bin.log //binlog日志文件expire_logs_days = 7 //binlog过期清理时间max_binlog_size = 100m //binlog每个日志文件大小binlog_cache_size = 4m //binlog缓存大小max_binlog_cache_size = 512m //最大binlog缓存大小三 MIXED说明对于执行的SQL语句中包含now()这样的时间函数，会在日志中产生对应的unix_timestamp()*1000的时间字符串，slave在完成同步时，取用的是sqlEvent发生的时间来保证数据的准确性。另外对于一些功能性函数slave能完成相应的数据同步，而对于上面指定的一些类似于UDF函数，导致Slave无法知晓的情况，则会采用ROW格式存储这些Binlog，以保证产生的Binlog可以供Slave完成数据同步。现在来比较以下 SBR 和 RBR 2中模式各自的优缺点：SBR 的优点：历史悠久，技术成熟binlog文件较小binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况binlog可以用于实时的还原，而不仅仅用于复制主从版本可以不一样，从服务器版本可以比主服务器版本高SBR 的缺点：不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。调用具有不确定因素的 UDF 时复制也可能出问题使用以下函数的语句也无法被复制：LOAD_FILE()UUID()USER()FOUND_ROWS()SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)INSERT ... SELECT 会产生比 RBR 更多的行级锁复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁对于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 语句会阻塞其他 INSERT 语句对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响存储函数(不是存储过程)在被调用的同时也会执行一次 NOW() 函数，这个可以说是坏事也可能是好事确定了的 UDF 也需要在从服务器上执行数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错执行复杂语句如果出错的话，会消耗更多资源RBR 的优点：任何情况都可以被复制，这对复制来说是最安全可靠的和其他大多数数据库系统的复制技术一样多数情况下，从服务器上的表如果有主键的话，复制就会快了很多复制以下几种语句时的行锁更少：INSERT ... SELECT包含 AUTO_INCREMENT 字段的 INSERT没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句执行 INSERT，UPDATE，DELETE 语句时锁更少从服务器上采用多线程来执行复制成为可能RBR 的缺点：binlog 大了很多复杂的回滚时 binlog 中会包含大量的数据主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生 binlog 的并发写问题UDF 产生的大 BLOB 值会导致复制变慢无法从 binlog 中看到都复制了写什么语句当在非事务表上执行一段堆积的SQL语句时，最好采用 SBR 模式，否则很容易导致主从服务器的数据不一致情况发生另外，针对系统库 mysql 里面的表发生变化时的处理规则如下：如果是采用 INSERT，UPDATE，DELETE 直接操作表的情况，则日志格式根据 binlog_format 的设定而记录如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何都采用 SBR 模式记录注：采用 RBR 模式后，能解决很多原先出现的主键重复问题。原文转载：https://www.cnblogs.com/xingyunfashi/p/8431780.html -
Mysql中definer引起的视图查询提示密码错误 这个问题会导致以下几个问题出现。mysqsl查询视图，函数时显示密码错误迁移数据库时，显示查询密码错误等1.mysql中的definer是什么，有什么作用？我们在mysql创建view、trigger、function、procedure、event时都会定义一个Definer=‘xxx’,类似如下：CREATE ALGORITHM = UNDEFINED DEFINER = `root`@`%` SQL SECURITY DEFINER VIEW `v_ questions` AS SELECT `q`.`id` AS `id`, `q`.`title` AS `title` FROM Test q; -- 或者像这样的： CREATE DEFINER=`root`@`%` PROCEDURE `user_count`() LANGUAGE SQL NOT DETERMINISTIC CONTAINS SQL SQL SECURITY DEFINER COMMENT '' BEGIN select count(*) from mysql.user; END加红的部分SQL SECURITY 其实后面有两个选项，一个为DEFINER，一个为INVOKERSQL SECURITY { DEFINER | INVOKER } ：指明谁有权限来执行。DEFINER 表示按定义者拥有的权限来执行INVOKER 表示用调用者的权限来执行。默认情况下，系统指定为DEFINER 以存储过程为例：（1）MySQL存储过程是通过指定SQL SECURITY子句指定执行存储过程的实际用户；（2）如果SQL SECURITY子句指定为DEFINER，存储过程将使用存储过程的DEFINER执行存储过程，验证调用存储过程的用户是否具有存储过程的execute权限和DEFINER用户是否具有存储过程引用的相关对象的权限；（3）如果SQL SECURITY子句指定为INVOKER，那么MySQL将使用当前调用存储过程的用户执行此过程，并验证用户是否具有存储过程的execute权限和存储过程引用的相关对象的权限；（4）如果不显示的指定SQL SECURITY子句，MySQL默认将以DEFINER执行存储过程。我们来看下面几个小例子。先授权一个： grant all on testdb.* to 'user1'@'%' identified by '000000' with grant option; 然后我们创建一个存储过程如下： USE `testdb`; DROP procedure IF EXISTS `user_count`; DELIMITER $$ USE `testdb`$$ CREATE DEFINER=`root`@`%` PROCEDURE `user_count`() LANGUAGE SQL NOT DETERMINISTIC CONTAINS SQL SQL SECURITY INVOKER COMMENT '' BEGIN select count(*) from mysql.user; END$$ DELIMITER ;用root帐号登陆： mysql> use testdb; Database changed mysql> call user_count(); +----------+ | count(*) | +----------+ | 3 | +----------+ 1 row in set (0.00 sec) Query OK, 0 rows affected (0.00 sec) 可以正常查询出来。 我们再用user1进行登陆： mysql> use testdb; Database changed mysql> call user_count(); ERROR 1142 (42000): SELECT command denied to user 'user1'@'localhost' for table 'user' 现系统报错查询不到了，这是因为我们在上述定义的SQL SECURITY值为INVOKER，存储过程执行过程中会以user1具有的权限来执行，其中调用到了mysql的库，而我们的user1帐户只有testdb库的使用权限，所以会返回失败。我们把上面的invoker改为definer再来试一下：update mysql.proc set security_type='DEFINER' where db='testdb' and name='user_count'; 再次用user1进行登陆： mysql> use testdb; Database changed mysql> call user_count(); +----------+ | count(*) | +----------+ | 3 | +----------+ 1 row in set (0.00 sec) Query OK, 0 rows affected (0.00 sec)2.如果方便修改mysql中所有已经定义到的definer？由于前期在测试库上开发的缘故，我们经常定义到的definer为root@%，后来搬移到生产库上又得改回来，存在着大量的更新，上百个的视图，函数等一个个改不免太麻烦并且也可能遗漏。如下为总结出的方便修改所有definer的方法，可以直到查漏补缺的作用。现在在mysql涉及的definer有view、trigger、function、procedure、event。我们一个个作介绍。1.修改function、procedure的definerselect definer from mysql.proc; -- 函数、存储过程update mysql.proc set definer='user@localhost'; -- 如果有限定库或其它可以加上where条件2.修改event的definerselect DEFINER from mysql.EVENT; -- 定时事件update mysql.EVENT set definer=' user@localhost ';3.修改view的definer相比function的修改麻烦点：select DEFINER from information_schema.VIEWS; select concat("alter DEFINER=user@localhost SQL SECURITY DEFINER VIEW ",TABLE_SCHEMA,".",TABLE_NAME," as ",VIEW_DEFINITION,";") from information_schema.VIEWS where DEFINER<>'user@localhost'; 查询出来的语句再执行一遍就好了。4.修改trigger的definer目前还没有具体方便的方法，可以借助工具端如HeidiSQL、sqlyog等来一个个修改。注意改前有必要锁表,因为如果改的过程中有其它表改变而触发，会造成数据不一致。Flush tables with readlockUnlock tables文章转载出处：https://www.cnblogs.com/zejin2008/p/4767531.html
-
-
linux主机下使用docker 导入导出 mysql数据库 1. 导出数据# mysql5.6为容器名称，也可以使用容器ID docker exec mysql5.6 sh -c 'exec mysqldump 【数据库名】 -uroot -p"$MYSQL_ROOT_PASSWORD"' | gzip > lanning.sql.gz2. 导入数据第一步：拷贝文件到容器docker cp lanning.sql mysql5.6:/data/lanning.sql 第二步：导入数据mysql -uroot -p"$MYSQL_ROOT_PASSWORD" dbname < lanning.sql
-
mysql 创建用户 mysql 8.0 以下创建-- 以下命令会创建一个可以任何IP主机 访问 的用户，并对db_name数据库具有 所有权限操作， GRANT ALL PRIVILEGES ON db_name.* TO 'username'@'%' IDENTIFIED BY '访问密码' WITH GRANT OPTIONmysql 8.0及以上创建 -- 创建账户(% 代表所有IP) create user 'username'@'%' identified by 'paaswrod'; -- 赋予权限，with grant option这个选项表示该用户可以将自己拥有的权限授权给别人 grant all privileges on gxxblw_db.* to 'username'@'%' with grant option; -- 改密码&授权超用户，flush privileges 命令本质上的作用是将当前user和privilige表中的用户信息/权限设置从mysql库(MySQL数据库的内置库)中提取到内存里 flush privileges;
