mysql架构组成

  1. 云栖社区>
  2. 博客>
  3. 正文

mysql架构组成

技术小牛人 2017-11-23 19:08:00 浏览546
展开阅读全文

错误日志:ErrorLog

        在mysql数据库中,错误日志功能是默认开启的。这个错误日志存储在mysql数据库的数据目录中。错误日志文件通常的名称为hostname.err,表示服务器的主机名。

        错误日志信息可以自己进行配置的,错误日志所记录的信息是可以通过log-error和log-warnings来定义的。其中log-warnings是定义是否将警告信息也定义至错误日志。默认情况下错误日志记录着服务器启动和关闭过程中的信息,服务器允许过程中的错误信息,事件调度器运行一个事件时产生的信息,在从服务器上启动服务器进程时产生的信息。

        mysql有很多系统变量可以设置,系统变量设置不同,会导致系统运行状态的不同。因此mysql提供查看系统设置和运行状态的命令。

            查看系统设置:

                show [global | session] variables [link_or_where]

                show variables: show the values of mysql system variables

            运行状态

                show [global | session] status [like_or_where]

                show status: provides server status information

            如何修改系统配置

                    方法一:配置文件设置my.cnf

                            binlog_cache_size=1M

                    方法二:set global binlog_cache_size=1048576

                一般而言,日志级别的定义没有会话变量都只是在全局级别下定义

                    show global variables like '%log_error%';

                    log_error定义为错误日志文件路径

                    log_error_verbosity

                更改错误日志位置可以使用log-error来设置形式

                    vim /etc/my.cnf

                    log-error=/usr/local/mysql/data/mysqld.err

                查看mysql错误日志

                    tail /usr/local/mysql/data/mysqld.err

                为了方便维护需要,有时候会希望将错误日志中的内容做备份并重新开始记录,就可以利用mysql的flush logs命令来告诉mysql备份旧日志文件并生成新的日志文件,备份文件名以.old结尾。

                删除错误日志

                        数据库管理员可以删除很长时间的之前的错误日志,保证mysql服务器上的硬盘空间。mysql数据库中,可以使用mysqladmin开启新的错误日志:mysqladmin -u root -p flush-logs也可以登录mysql数据库中使用flush logs语句来开启新的错误日志。

                    在5.5.7之后,服务器将关闭此项功能,只能使用重命名原来的错误日志文件,手动冲洗日志创建一个新的

二进制日志:binarylog & binary log index

        二进制日志,就是binlog。主要用于记录修改数据或有可能引起数据改变的mysql语句,记录了语句发送时间,执行时长,操作的数据等。通过二进制日志可以查询mysql数据库中进行了哪些变化。一般大小体积上限为1G。

        当我们通过log-bin=file_name打开了记录的功能之后,mysql会将所有修改数据库数据的query以二进制形式记录到日志文件中,日志中并不仅限于query语句这么简单,还包括每一条query所执行的时间,所消耗的资源,以及相关的事务信息。和错误日志一样,binlog记录功能同样需要log-bin=file_name参数的显显式指定才能开启,如果未指定file_name,则会在数据目录下记录为myslq-bin.******

        附加选项参数:

            max_binlog_size设置binlog的最大存储上限,一般设置为512M或1G,一般不能超过1G。当日志到达上限时,mysql会重新创建一个日志开始继续记录。为了保证事务安全,mysql不会将同一个事务分开记录到两个binlog中。

            binlog-do-db=db_name参数明确告诉mysql,需要对某个数据库记录binlog,mysql会忽略其他数据库执行的query,而仅仅记录针对指定数据库执行query。

            binlog-ignore-db=db_name,显式指定忽略某个数据库的binlog记录,当指定了这个参数之后,mysql会记录指定数据库以外所有的数据库的binlog。

            binlog-ignore-db=db_name与binlog-do-db=db_name两个参数中的db_name不是指query语句更新的数据所在的数据库,而是执行query的时候当前所处的数据库。不论更新哪个数据库的数据,mysql仅仅比较当前连接所处的数据库与参数设置的数据库名,而不会分析query语句所更新数据所在的数据库

            mysql-bin.index文件的功能是记录所有binary log的绝对路径,保证mysql各种线程能够顺利的根据他找到所需要的binary log文件。

            binlog_cache_size=32768    binglog_cache_size:一个事务,在没有提交的时候产生的日志记录到cache中,等到事务提交需要提交的时候,则把日志持久化到磁盘。一般来说,如果我们的数据库中没有什么大事务,2MB-4MB。如果数据库大事务较多,写入量大,可与适当调高。我们可以通过binlog_cache_use 以及 binlog_cache_disk_use来分析设置的binlog_cache_size是否足够,是否有大量的binlog_cache由于内存大小不够而使用临时文件(binlog_cache_disk_use)来缓存了。

            binglog_stmt_cache_size=32768    当事务事务语句使用二进制日志缓存,但是超出binlog_stmt_cache_size时,使用一个临时文件来存放这些语句。

                事务表支持将批处理当做一个完整的任务统一提交或回滚,即对包含在事务中的多条语句要么全执行,要么全不执行。

                非事务表则不支持此种操作,批处理的语句如果遇见错误,在错误钱的语句执行成功,之后的则不执行。

                log_bin=mysql-bin指定binlog的位置,默认在数据目录下。

                binlog-format={ROW | statement | mixed}指定二进制日志的类型,默认为MIXED。mysql复制主要有三种方式:基于sql语句的,基于行的复制,混合模式复制。对应的,binlog的格式也有三种:statement,row,mixed。

                    STATEMENT模式SBR

                        每一条修改的sql语句会记录到binlog中,优点是并不需要记录每一行的数据变化,减少binlog日志量,节约io,提高性能。缺点是在某些情况下会导致master-slave中的数据不一致。

                    ROW模式RBR

                        不记录每条sql语句的信息,仅需要记录哪条数据被修改了,修改成怎么样。缺点是会产生大量的日志,让日志暴涨

                    MIXED模式MBR

                        一般的复制使用STATEMENT模式保持binlog,对于STATEMENT模式无法复制的操作使用ROW模式保存binlog,mysql会根据执行的sql语句选择日志保持方式。即交替使用行和语句,有mysql服务器自行判断。其中基于行的定义格式数据量会大一些但是可以保证数据的准确性。

                    sync_binlog=10    设定多久同步一次二进制日志至磁盘文件中,0表示不同步,任何正数值都表示对二进制每多少次写操作之后同步一次。当autocammit的值为1时,每条语句的执行都会引起二进制日志同步,否则每个事务的提交会引起二进制日志同步。

                    max_binlog_cache_size={4096..}    二进制日志缓存空间大小,5.5.9及以后的版本仅应用与事务缓存,其上限由max_binlog_stmt_cache_size决定。

                    max_binlog_stmt_cache_size    二进制日志缓存空间大小,5.5.9及以后的版本仅应用于事务缓存。

                    expire_log_days     设定二进制日志的过期天数,超出此天数的二进制日志文件将被自动删除。默认为0,表示不启用过期自动删除功能。如果启用此功能,自动删除工作通常发生在mysql启动或flush日志时。

                    通过编辑my.cnf中的log-bin选项可以开启二进制日志

                        格式:log-bin [=DIR/[filename]]

                        其中,DIR参数指定二进制文件的存储路径,filename参数指定二级制文件的文件名,其形式为filename.number,numer的形式为000001,000002等,每次重启mysql服务或允许mysql > flush logs,都会生成一个新的二进制日志文件,这些日志文件的number会不断地递增。

                        查看二进制日志;

                            二进制日志的定义方式为二进制格式,使用此格式可以存储更多的信息,并且可以使写入二进制日志的效率更高。但是不能直接使用查看命令打开并查看二进制日志。

                        当前使用的二进制文件及所处位置:show master status;

                        查看二进制日志信息的命令:show binlog events\G;

                        查看指定日志的二进制信息:

                            二进制日志的记录位置:通常为1上一个事件执行结束时间的位置

                            执行偏移量:show binlog events in

                        命令查看二进制日志:

                            由于无法使用cat等方式直接打开并查找二进制日志,所有必须使用mysqlbinlog命令。当时当正在执行mysql读写操作时建议不要使用此打开正在使用的二进制日志文件,若非要打开可flush logs。

                    删除二进制日志信息:

                        二进制日志会记录大量的信息,如果长时间不清理二进制日志,将会浪费很多的磁盘空间。但是删除之后可能导致数据库崩溃时无法进行恢复,所以若要删除二进制日志首先将其和数据库备份一份,其中也只能删除因为这样可能会给数据库带来错误的。若非要删除二进制日志需要导出备份数据库和二进制日志文件进行压缩归档存储。

                    根据文件或时间点来删除二进制日志:

                        purge {binary | master} logs {to 'log_name' | before datetiem_expr}

                    其中to log_name表示把这个文件之前的其他文件都删除掉,也可使用before datetime_expr指定把哪个时间之前的之前的二进制文件删除了。

                    删除所有的二进制日志

                        reset master;

    事务日志或称redo日志

            事务日志innodb特有的日志可以帮助提高事务的效率。使用事务日志,存储引擎在修改表数据时只需要修改其内存拷贝,再把修改行为记录到持久在硬盘上的事务日志中,而不用每次都将修改的数据本身持久到磁盘,事务日志采用追加的方式,因此写日志的操作是磁盘上一小块区域内的顺序i/o,而不像随机i/o需要在磁盘的多个地方移动磁头,所以采用事务日志的方式相对来说快得多。

            事务日志持久以后,内存中被修改的数据在后台可以慢慢的刷回到磁盘,目前大多数的存储引擎都是这样实现的。


            如果数据的修改已经记录到事务日志并持久化,但数据本身还没有写回磁盘,此时系统崩溃,存储引擎在重启时能够自动恢复这部分修改的数据。具有的恢复方式则视存储引擎而定。

本文转自   宏强   51CTO博客,原文链接:http://blog.51cto.com/tanhong/1903108

网友评论

登录后评论
0/500
评论
技术小牛人
+ 关注