Mysql數據庫的用戶和日誌管理
阿新 • • 發佈:2018-02-25
commit ans mys mat 2個 丟失 auth cache 執行
Mysql數據庫的用戶和日誌管理
數據庫的用戶管理
1.mysql用戶賬號管理 用戶賬號 user@host user:賬戶名稱 host:此賬戶可通過哪些客戶端主機請求創建連接線程,可以是ip、主機名或network。 %:任意長度的任意字符; _:任意單個字符; 1)新建用戶 create user ‘user_name‘@‘來源地址‘ [identified by [password]‘密碼‘]; help create user create user user_specification [, user_specification] ... user_specification:user [identified by [password] ‘password‘| identified with auth_plugin [as ‘auth_string‘]] 2)設置密碼 1》set set password=password(‘密碼‘); ##修改當前登錄用的密碼 set password for ‘user_name‘@‘來源地址‘=password(‘密碼‘); ##設置其他用戶的密碼 help set password set password [for user]={password(‘cleartext password‘)| old_password(‘cleartext password‘)| ‘encrypted password‘} 2》update update 庫.表 set password=password(‘ ‘) where user=‘user_name‘ and host=‘host_addr‘; 3》mysqladmin -uuser_name -hhost_addr -p password ‘new_password‘ 3)刪除用戶 drop user ‘user_name‘@‘來源地址‘... help drop DROP USER user [, user] ... 4)重命名及修改主機 rename user ‘user_name_old‘@‘host_old‘ to ‘user_name_new‘@‘host_new‘; ##可以只是修改用戶名或只是修改主機。 help rename user RENAME USER old_user TO new_user [, old_user TO new_user] ... 5)mysql 重新加載授權表 flush privileges 2.忘記root的密碼的解決方法 方法一: 1)關閉mysqld服務 service mysqld stop Shutting down MySQL.... [ OK ] 2)跳過grant表授權,進入安全模式,使用--skip-grant-tables選項,並在後臺運行 mysqld_safe --skip-grant-tables& jobs [1]+ Running mysqld_safe --skip-grant-tables & 3)進入安全模式修改密碼 mysql MariaDB [(none)]> use mysql; MariaDB [mysql]> update user set Password=password(‘xm1234‘) where user=‘root‘; MariaDB [mysql]> flush privileges; MariaDB [mysql]> exit killall -u mysql 4)重啟mysql服務並嘗試 service mysqld start mysql -uroot -p 方法二: vim /etc/mysql/my.cnf skip_grant_tables service mysqld restart mysql MariaDB [(none)]> use mysql; MariaDB [mysql]> update user set Password=password(‘xm1234‘) where user=‘root‘; MariaDB [mysql]> flush privileges; MariaDB [mysql]> exit vim /etc/mysql/my.cnf skip_grant_tables 去掉 service mysqld restart mysql -uroot -p 3.用戶權限設置 mysql權限類別 庫級別,表級別,字段級別,管理類,程序類 管理類: create user reload lock tables replication client, replication slave shutdown file show databases process super 程序類: create,alter,drop,execute function procedure trigger 庫和表級別: create,alter,drop,show,grant index view 字段級別: 元數據: db, host, user tables_priv, column_priv, procs_priv, proxies_priv 所有權限: all, all privileges show grants for 用戶名; grant select on 數據庫名.* to 用戶名; ##給用戶的數據庫的所有權限 revoke select on 數據庫名.* to 用戶名; ##grant的反操作,去除權限; 1》設置用戶權限(用戶不存在時則是新建用戶) grant 權限列表 on 庫名.表名 to ‘用戶名‘@‘來源地址‘ [identified by ‘密碼‘]; grant select on 數據庫名.* to 用戶名; grant all on *.* to 用戶名; flush privileges; ##刷新權限 help grand grant priv_type [(column_list)] [, priv_type [(column_list)]] ... on [object_type] priv_level to user_specification [, user_specification] ... [require {none | ssl_option [[and] ssl_option] ...}] [with with_option ...] grant proxy on user_specification to user_specification [, user_specification] ... [with grant option] object_type: table | function | procedure priv_level: * | *.* | db_name.* | db_name.tbl_name | tbl_name | db_name.routine_name user_specification: user [identified by [password] ‘password‘ | identified with auth_plugin [as ‘auth_string‘] ] ssl_option: ssl | x509 | cipher ‘cipher‘ | issuer ‘issuer‘ | subject ‘subject‘ with_option: grant option | max_queries_per_hour count | max_updates_per_hour count | max_connections_per_hour count | max_user_connections count 示例: create user ‘jeffrey‘@‘localhost‘ identified by ‘mypass‘; grant all on db1.* to ‘jeffrey‘@‘localhost‘; grant select on db2.invoice to ‘jeffrey‘@‘localhost‘; grant usage on *.* to ‘jeffrey‘@‘localhost‘ with max_queries_per_hour 90; grant all on *.* to ‘root‘@‘%‘ indentified by ‘xxxxx‘; grant select on imployee_salary.* to ‘amber‘@‘localhsot‘ identified by ‘xxxx‘; flush privileges;##刷新權限 2》查看用戶權限 show grants; ##查看當前登錄用戶的授權信息。 show grants for ‘用戶名‘@‘主機地址‘; help show grants show grants [for user] show grants; show grants for current_user; show grants for current_user(); 3》撤銷用戶權限 revoke 權限列表 on 庫名.表名 from ‘用戶名‘@‘來源地址‘ revoke select on ‘數據庫名‘.* from ‘用戶名‘@‘來源地址‘; revoke all on *.* from ‘用戶名‘@‘來源地址‘; flush privileges; ##刷新權限 help revoke revoke priv_type [(column_list)][, priv_type [(column_list)]] ... on [object_type] priv_level from user [, user] ... revoke all privileges, grant option from user [, user] ... revoke proxy on user from user [, user] ... 4》常見權限列表
數據庫的日誌管理
mysql日誌: 錯誤日誌:log_error,log_warnings 通用查詢日誌:general_log 二進制日誌:binlog 慢速查詢日誌:log_slow_queries 中繼日誌:relay_log 事務日誌:innodb_log 由於版本的不同,以下的目錄文件目錄也有所不同 1)錯誤日誌 錯誤日誌本身所定義的內容本身是可以定義的 。 錯誤日誌記錄的信息: 1》mysqld啟動和關閉過程中輸出的信息。 未必是錯誤信息,比如mysql是如何去初始化存儲引擎的過程記錄在錯誤日誌裏等等 2》mysqld運行中產生的錯誤信息。 比如sock文件找不到,無法加載mysql數據庫的數據文件,如果忘記初始化mysql或data dir路徑找不到,或權限不正確等,都會記錄在此。 3》事件調度器(event scheduler)運行時產生的信息。 一旦mysql調度啟動一個計劃任務的時候,它也會將相關信息記錄在錯誤日誌中。 4》 主從復制架構中,從服務器復制線程啟動時產生的日誌; 修改主配置文件my.cnf [mysqld] log-error=mysql_error.log(絕對路徑或若直接文件名則會存儲到數據目錄下) log_warnings={on|off|2}:將不將警告信息記錄日誌 log_warnings表示警告信息是否記錄在錯誤日誌中,1和0也就是on和off表示記錄和不記錄,2則表示失敗拒絕的連接信息。 在mysql服務器上查看錯誤日誌的配置 mysql> show global variables like ‘%log%‘; | log_error |/mydata/data/localhost.err | | log_warnings | 1 | 2)通用查詢日誌 mysql所有查詢語句都會被記錄。 默認關閉此項記錄,一般作調試用,平時開啟會記錄大量數據占用磁盤空間。 存儲位置:文件,表(table,mysql.general_log) 默認,存儲在數據目錄下。 修改主配置文件my.cnf。 [mysqld] general_log={on|off} general_log_file=mysql_general.log (絕對路徑或若直接文件名則會存儲到數據目錄下) log_output={file|table|file,table|none}:日誌輸出類型 在mysql服務器上查看查詢日誌的配置 MariaDB [(none)]> show global variables where variable_name like ‘%general_log%‘ or variable_name=‘log_output‘; +------------------+---------------+ | Variable_name | Value | +------------------+---------------+ | general_log | OFF | | general_log_file | localhost.log | | log_output | FILE | +------------------+---------------+ 3)二進制日誌(非常重要) 1》用於記錄引起數據改變或存在引起數據改變的潛在可能性的語句(statement)或改變後的結果(row),也可能是二者混合。 2》包含了所有更新了的數據或者已經潛在更新了數據的所有語句,記錄了數據的更改以及數據更改的事件events和位置position。 3》主要目的是在恢復時能夠最大可能地恢復數據庫,默認開啟的。 4》修改主配置文件my.cnf。 log_bin=/path/to/bin_log_file: 這是個只讀變量,表明存放日誌的目錄位置,不能在此處寫on或off,若不指定路徑會存儲在數據目錄下。 max_binlog_size=1073741824: 設置單個二進制文件的最大尺寸,以字節為單位,超過此值大小就會自動滾動。 sync_binlog={1|0|N}: 表示每幾次事務提交後是否立即將內存中的二進制日誌同步到內存(binlog_cache)中。 1表示立即提交;0則不提交;N可為任意值,表示每N次;值不同對應的性能也不同,0和1的性能差別可高達5倍之多。寫入磁盤的操作是使用fdatasync()函數。 binlog_format={statement|row|mixed}: binlog日誌存放的格式 expire_logs_days=N: 二進制日誌的有效天數 5》功用:重放 6》相關說明 binlog_format={statement|row|mixed} statement:語句,記錄了多數據庫作出修改的語句; row:行,記錄 了對 數據庫作出修改的語句所影響到的數據行以及這些行的修改; mixed:混編,混合上述兩種模式; sql_log_bin={on|off} 控制某會話中的“寫”操作語句是否會被記錄於日誌文件中 是個會話級別的變量,只能在當前會話中使用set命令來進行設置session.sql_log_bin={on|off} 不能配置在my.cnf文件中 7》可以用mysqlbinlog命令查看二進制日誌文件。 mysqlbinlog: yyyy-mm-dd hh:mm:ss --start-datetime= --stop-datetime= -j, --start-position=# --stop-position=# --user, --host, --password 8》在mysql中查看二進制 查看二進制日誌文件列表: mysql> show master|binary logs; 查看當前正在使用的二進制日誌文件: mysql> show master status; 查看二進制日誌文件中的事件: mysql> show binlog events [in ‘log_name‘] [from pos] [limit [offset,] row_count] 查看二進制日誌的參數配置 MariaDB [(none)]> show global variables where variable_name like ‘%log_bin%‘ or variable_name like ‘%binlog%‘; +-----------------------------------------+----------------------+ | Variable_name | Value | +-----------------------------------------+----------------------+ | binlog_annotate_row_events | OFF | | binlog_cache_size | 32768 | | binlog_checksum | NONE | | binlog_direct_non_transactional_updates | OFF | | binlog_format | STATEMENT | | binlog_optimize_thread_scheduling | ON | | binlog_stmt_cache_size | 32768 | | innodb_locks_unsafe_for_binlog | OFF | | log_bin | ON | | log_bin_trust_function_creators | OFF | | max_binlog_cache_size | 18446744073709547520 | | max_binlog_size | 1073741824 | | max_binlog_stmt_cache_size | 18446744073709547520 | | sql_log_bin | ON | | sync_binlog | 0 | +-----------------------------------------+----------------------+ 日誌滾動,單個二進制達到指定大小時會滾動,重啟mysql後也會自動滾動,也可以進行手動滾動。 手動滾動二進制日誌 MariaDB [(none)]>flush logs 9》清除二進制日誌 清除所有日誌(不存在主從復制關系) mysql> reset master; 清除指定日誌之前的所有日誌 mysql> purge master logs to ‘日誌‘; 清除某一時間點前的所有日誌 mysql> purge master logs before ‘年-月-日 時:分:秒‘; 清除 n 天前的所有日誌 mysql> purge master logs before current_date - interval 10 day; 由於二進制日誌的重要性,請僅在確定不再需要將要被刪除的二進制文件, 或者在已經對二進制日誌文件進行歸檔備份, 或者已經進行數據庫備份的情況下,才進行刪除操作,且不要使用 rm 命令刪除。 10》二進制日誌事件格式: # at 553 #160831 9:56:08 server id 1 end_log_pos 624 query thread_id=2 exec_time=0 error_code=0 set timestamp=1472608568/*!*/; begin /*!*/; 事件的起始位置:# at 553 事件發生的日期時間:#160831 9:56:08 事件發生的服務器id:server id 1 事件的結束位置:end_log_pos 624 事件的類型:query 事件發生時所在服務器執行此事件的線程的id: thread_id=2 語句的時間戳與將其寫入二進制日誌文件中的時間差:exec_time=0 錯誤代碼:error_code=0 設定事件發生時的時間戳:set timestamp=1472608568/*!*/; 事件內容:begin 4)慢速查詢日誌 記錄所有執行時間超過long_query_time秒的sql語句,可用於找到執行時間長的查詢,以用於優化。 默認未開啟,開啟優先級比查詢日誌高,默認是超過10秒的才會被記錄。 存儲位置:文件,表(table,mysql.slog_log) 修改主配置文件/etc/my.cnf,在[mysqld]下添加“long_query_time”和“log-slow-queries=文件路徑名”,重啟mysqld服務。 log_slow_queries={on|off}:是否開啟慢查詢日誌(5.5以前) slow_query_log={on|off}:是否開啟慢查詢日誌(和上面沒有區別,5.6以後) slow_query_log_file=xxxx-slom.log:慢查詢日誌存放位置,默認為“主機名-slow.log”。相對路徑的話,默認為數據目錄下。 log_output={file|table|file,table|none}:表示存放日誌的方式 log_query_time=N :表示多長時間的查詢被認為慢查詢,默認為10秒。 log_queries_not_using_indexes={on|off} :表示運行的sql語句沒有使用到索引,是否也被當作慢查詢語句記錄。 log_throttle_queries_not_using_indexes={on|off}:5.6.5引入的,沒喲使用索引的查詢語句是否胡被當作慢查詢語句記錄到慢查詢日誌中。 log_slow_filter=admin,filesort,filesort_on_disk,full_join,full_scan,query_cache,query_cache_miss,tmp_table,tmp_table_on_disk log_slow_rate_limit log_slow_verbosity 在mysql服務器上查看慢查詢的參數 MariaDB [(none)]>show global variables where variable_name like ‘%slow_query%‘ or variable_name=‘log_output‘ or variable_name=‘long_query_time‘ or variable_name like ‘log_slow%‘; mysql自帶了對慢查詢日誌的統計分析工具:mysqldumpslow 5)中繼日誌: 中繼日誌用於主從復制架構中的從服務器上,從服務器的 slave 進程從主服務器處獲取二進制日誌的內容並寫入中繼日誌,然後由 I/O 進程讀取並執行中繼日誌中的語句。 6)事務(重做)日誌: 1》事務型存儲引擎innodb用於保證事務特性的日誌文件,redo log 和undo log 2》出於性能和故障恢復的考慮,MySQL 服務器不會立即執行事務,而是先將事務記錄在日誌裏面,這樣可以將隨機I/O轉換成順序I/O,從而提高I/O性能。 3》事物日誌默認情況下會有兩個文件,名稱分別為ib_logfile0和ib_logfile1。當其中一個寫滿時,MySQL會將事務日誌寫入另一個日誌文件(先清空原有內容)。 4》當 MySQL 從崩潰中恢復時,會讀取事務日誌,將其中已經 commit 的事務寫入數據庫,沒有 commit 的事務 rollback 。 5》在事物提交時,innodb是否將緩沖到文件中同步,只要提交則立刻同步,同時又不會保證每個語句都同步,因此性能不會有特別大的影響 6》mysql中顯示事務日誌的相關參數 MariaDB [(none)]> show global variables where variable_name like ‘%innodb_log%‘ or variable_name like ‘innodb_%_log%‘ or variable_name like ‘innodb_locks%‘; +-------------------------------------------+---------+ | Variable_name | Value | +-------------------------------------------+---------+ | innodb_flush_log_at_trx_commit | 1 | | innodb_locks_unsafe_for_binlog | OFF | | innodb_log_block_size | 512 | | innodb_log_buffer_size | 8388608 | | innodb_log_file_size | 5242880 | | innodb_log_files_in_group | 2 | | innodb_log_group_home_dir | ./ | | innodb_mirrored_log_groups | 1 | | innodb_recovery_update_relay_log | OFF | | innodb_use_global_flush_log_at_trx_commit | ON | +-------------------------------------------+---------+ 如果innodb_flush_log_at_trx_commit設置為0,log buffer將每秒一次地寫入log file中,並且log file的flush(刷到磁盤)操作同時進行。 該模式下,在事務提交的時候,不會主動觸發寫入磁盤的操作。 如果innodb_flush_log_at_trx_commit設置為1,每次事務提交時MySQL都會把log buffer的數據寫入log file,並且flush(刷到磁盤)中去. 如果innodb_flush_log_at_trx_commit設置為2,每次事務提交時MySQL都會把log buffer的數據寫入log file,但是flush(刷到磁盤)操作並不會同時進行。 該模式下,MySQL會每秒執行一次 flush(刷到磁盤)操作。 定義內存空間的大小,萬一都寫在buffer裏面,如果進程崩潰,也會丟失事物,因此避免這種情況,一旦事物提交了,那麽需要立即同步到磁盤中,而不是間斷同步,所以有參數: |innodb_log_buffer_size |8388608 | 每個日誌的單位大小為5MB,如果有些大數據的話,則需要將其調大,否則恢復起來會比較慢,但是太大了也會導致恢復比較慢 |innodb_log_file_size |5242880 | 在每個組裏面提供2個文件,上面有提到過 |innodb_log_files_in_group |2 | 定義事物日誌組的位置,一般來講會有2個日誌,一個寫滿後會重建立文件(達到輪詢功能,寫滿後會同步到磁盤並將其清空)。 一般來講,日誌文件大小是固定的,凡是mysql已啟動的日誌空間會在磁盤上立即分配,因為他們的主要功能是將隨機I/O轉為順序I/O ,默認大小是每個文件為5MB,明確說明事物日誌的路徑保存在./ 表示在當前路徑下 |innodb_log_group_home_dir |./ | 同一個日誌文件對日誌組做鏡像,當然,需要存放在不同的磁盤上 |innodb_mirrored_log_groups |1 |
Mysql數據庫的用戶和日誌管理