mysql权限的误操作的恢复

mysql权限的误操作的恢复

原因:由于误操作,我把repl用户授予了所有权限,但删除了数据库中的其他用户及权限,因此repl用户虽然具有操作所有数据库的权限,但没有grant权限,所以若想授予其他用户权限,来管理数据库,出现这种状况就酷毙了,没有授予权限怎麽办?

误操作过程

mysql >grant all on *.* to ‘repl‘@‘192.168.1.%‘ identified by ‘123456‘;

mysql> flush privileges;

授予完以后,我把其他的所有用户全部都删除了,再来查看此时的用户

mysql> select host,user,password from mysql.user;
+--------------+------+-------------------------------------------+
| host         | user | password                                  |
+--------------+------+-------------------------------------------+
| 192.168.1.%  | repl | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |
+--------------+------+-------------------------------------------+

查看授予用户的权限会发现grant权限为N

mysql> select * from mysql.user\G;

*************************** 2. row ***************************
                  Host: 192.168.1.%
                  User: repl
              Password: *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9
           Select_priv: Y
           Insert_priv: Y
           Update_priv: Y
           Delete_priv: Y
           Create_priv: Y
             Drop_priv: Y
           Reload_priv: Y
         Shutdown_priv: Y
          Process_priv: Y
             File_priv: Y
            Grant_priv: N
       References_priv: Y
            Index_priv: Y
            Alter_priv: Y
          Show_db_priv: Y
            Super_priv: Y
Create_tmp_table_priv: Y
      Lock_tables_priv: Y
          Execute_priv: Y
       Repl_slave_priv: Y
      Repl_client_priv: Y
      Create_view_priv: Y
        Show_view_priv: Y
   Create_routine_priv: Y
    Alter_routine_priv: Y
      Create_user_priv: Y
            Event_priv: Y
          Trigger_priv: Y
Create_tablespace_priv: Y
              ssl_type:
            ssl_cipher:
           x509_issuer:
          x509_subject:
         max_questions: 0
           max_updates: 0
       max_connections: 0
  max_user_connections: 0
                plugin: mysql_native_password
authentication_string:
      password_expired: N

我的做法:

mysql> update mysql.user set  Grant_priv=‘Y‘ where user=‘repl‘ and host=‘192.168.1.%‘;

mysql>\q

再次登录

mysql >flush privileges;

你会发现令人高兴的现象,授予其它用户权限竟然OK了

mysql> grant all on *.* to ‘test1‘@‘192.168.1.%‘ identified by ‘123456‘;
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

时间: 2024-08-05 10:54:21

mysql权限的误操作的恢复的相关文章

MySQL【Update误操作】回滚(转)

前言:      继上一篇MySQL[Delete误操作]回滚之后,现在介绍下Update回滚,操作数据库时候难免会因为“大意”而误操作,需要快速恢复的话通过备份来恢复是不太可能的,因为需要还原和binlog差来恢复,等不了,很费时.这里说明因为Update 操作的恢复方法:主要还是通过binlog来进行恢复,前提是binlog_format必须是Row格式,否则只能通过备份来恢复数据了.和上一篇的条件一样.方法:     条件:开启Binlog,Format为Row.     步骤:1.通过M

rm-rf 误操作的恢复过程

很多DBA一定对rm -rf深恶痛绝吧,没准哪天自己一个犯迷糊就把数据库给消灭了,然后,就没有然后了--那万一--真的发生了这样的不幸,是否真的就无药可救了吗?未必,还是有解决方法的,也许某天当你不幸遇到,就可以用来救自己了.这里做恢复操作的前提是没有可用的rman备份,或者数据库冷备份等,也就是说,没有任何备份. 一.登陆SQLPLUS,并启动数据库 [[email protected] ~]$ sqlplus / as sysdba SQL*Plus: Release 10.2.0.1.0

【转】SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

4号,公司的生产数据表被全部删除,目前没有找到原因,由于刚接触SQL不久,所以短时间内不会还原,也不敢动被原服务器,于是就将原服务器停掉,拷贝出里面的PPD数据库文件,留作备份:近几天在自己的电脑上尝试修复,一直没有成功,细读了一下<SQL2005技术内幕——存储引擎>了解到删除列.删除表这些操作不会直接对每一行数据进行操作,而是直接改变他们的物理指向地址的ID,专业术语我也不是很清楚,我的理解是这样的,有时间再弄清楚,不过这足以让我明白被删除的表还是存在mdf文件中,其改变的便宜地址记录在日

Linux系统目录权限chmod误操作权限修复方法

Linux中,如果意外误操作将/目录权限批量设置,比如chmod -R 777 / ,系统中的大部分服务以及命令将无法使用,这时候可以通过系统自带的getfacl命令来拷贝和还原系统权限,若是其他系统目录被误操作,同样可行.修复的方法如下: 1.通过一台权限正常的Linux(最好内核版本和故障服务器相同) getfacl -R / >systemp.bak 2.如果异常服务器未重启等操作并且连接未端,可以使用scp命令将正常的备份文件传至异常服务器中,命令如下: scp [email prote

MySQL的delete误操作的快速恢复方法

1. 根据误操作时间定位binlog位置找到数据库的binlog存放位置,当前正在使用的binlog文件里面就有我们要恢复的数据.一般生产环境中的binlog文件都是几百M乃至上G的大小,我们不能逐行去找被删除的数据在什么位置,所以记住误操作的时间很重要,我们可以通过mysqlbinlog命令的--start-datetime参数快速定位数据位置.比如误操作时间为20181104151800,解析出的binlog内容: [[email protected] mysql]# mysqlbinlog

SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这种情况,一般都是没有做备份,不然也不会来发问了.首先要冷静,否则会有更大的灾难.直到你放弃. 解决方法: 对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的工具Log Exploer,听说还挺好用的,这个网上大把教程,这里就不多说了.但是唯一遗憾的是,不支持2008及更高版本,这

SCPPO:SQL误操作如何恢复?

[前言] 今天研究项目中自己有疑惑的一块儿内容应该是这个系统的核心-数据从上传的Access中解析出来(ETL的贡献)经过一系列的存储过程将数据放到数据库表中(每天凌晨都会定时的执行这一系列操作)这只是今天的引子,不具体深入的讲解下去,小编会在接下来的博文中更加深入的为大家分享: 在分析这块儿的时候无意在服务器上发现一款软件-ApexSQL Log:之前没接触过出于好奇就去网上查了一下它是干嘛用的,这一查不要紧,又燃起了自己新的兴趣,仿佛一切的一切上天冥冥之中自有安排!为何这么说?小编下面为大家

logminer挖掘归档日志,针对DDL误操作的恢复

日志挖掘,未开启补充日志功能,利用归档对DDL操作进行恢复:        Oracle   的日志文件中,对于表等用户对象(Object),并不是保存名字,而是保存一个ID号.建立字典文件的目的就是使logminer在分析时可以将Object   ID翻译成我们所熟悉的对象名.       建立字典文件之前,先要确保数据库的初始化参数   UTL_FILE_DIR   已经正确地设置.通过命令可以查看是否有字典文件:show parameters utl_file_dir; [email pr

git操作——git pull 撤销误操作,恢复本地代码

需求 开发的代码还未commit到git本地仓库,就从git远程仓库上pull了代码,导致开发的代码直接被冲掉,需要退回到上一个版本代码. 操作 进入到项目git本地仓库文件夹下 打开cmd窗口,执行命令:git reflog 找到需要回退的版本,执行命令:git reset --hard [email protected]{n} 如执行:git reset --hard 61a942c 原文地址:https://www.cnblogs.com/zuiyue_jing/p/11123654.ht