DM7中log_commit.log日志文件存储路径的修改方式
- 格式:pdf
- 大小:331.47 KB
- 文档页数:3
Docker下mysql容器开启binlog⽇志(保留7天)现有需求开启⽤Docker容器启动的mysql数据库的binlog,以作为 ⽇志记录 和 数据恢复,我们了解了MySQL的binlog⽇志的开启⽅式以及binlog⽇志的⼀些原理和常⽤操作,我们知道,binlog有两⼤作⽤,⼀个是使⽤binlog恢复数据,另⼀个就是⽤来做主从复制。
本篇笔记就是来记录如何使⽤开启binlog⽇志和做数据恢复。
当然了,使⽤binlog⽇志所恢复的数据只能是部分数据,并不能够使⽤binlog⽇志来做数据库的备份,如果想要做数据库备份,依然要使⽤我们传统的备份⽅法,⽽binlog可以作为增量备份。
以供笔记和学习,以下就是开启binlog⽇志的步骤过程:1.⾸先,在实现前我是在虚拟机上做的实验,环境如下:[root@localhost cloud]# cat /etc/centos-releaseCentOS Linux release 7.4.1708 (Core)数据库镜像版本[root@localhost cloud]# docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEdocker.io/mysql 5.7 5195076672a7 13 days ago 371 MB2.下载mysql 数据库镜像docker pull mysql:5.73.在启动容器之前先要创建好要挂载出来的⽬录⽂件⼀个myql的配置⽬录 在容器:/etc/mysql ,这⾥可以从其他容器中拷贝过来docker cp mysql:/etc/mysql /etc/mysql第⼆个mysql数据⽬录 /var/lib/mysql 保存了数据库、表等数据信息4.启动Mysql5.7镜像⼀个实例docker run -d --name mysql--privileged=true-p 3306:3306-e MYSQL_ROOT_PASSWORD=123456-v /etc/mysql:/etc/mysql-v /opt/mysql:/var/lib/mysql-v /etc/localtime:/etc/localtimedocker.io/mysql:5.75.启动好后,⽤mysql客户端⼯具边接,在未设置之前,先查看⼀下,mysql5.7是否默认开启,查看脚本如下:show variables like '%log_bin%'结果如下:看得出mysql5.7默认是未开启的,下⾯就开始设置6.找到刚挂载到本地的mysql设置⽬录 /etc/mysqlvim /etc/mysql/mysql.conf.d/f在以上修改的⽂件下⽅,添加上红框中的两条这⼀个参数的作⽤是mysql会根据这个配置⾃动设置log_bin为on状态,⾃动设置log_bin_index⽂件为你指定的⽂件名后跟.index第⼆个参数 ,⽤的如果是5.7及以上版本的话,重启mysql服务会报错,这个时候我们必须还要指定这样⼀个参数,随机指定⼀个不能和其他集群中机器重名的字符串,如果只有⼀台机器,那就可以随便指定了。
Mysql,MariaDB 的默认数据存放在/var/lib/mysql 目录下,如果不想放到此处,或者是想要程序和数据分离,或者是磁盘原因需要切换到其他路径,则可以通过修改datadir系统变量来达成目的。
1.停止mysql服务2.创建数据存放目录3.拷贝数据到新位置4.备份原来的数据查看f发现它就一句:所以继续备份:5.修改f文件在mysqld节点下添加以下内容:datadir=/usr/local/iternal/mysql_data/mysqlsocket=/var/lib/mysql/mysql.sock#default-character-set=utf8character_set_server=utf8slow_query_log=onslow_query_log_file=/usr/local/iternal/mysql_data/slow_query_log.loglong_query_time=2其中,也只有datadir 和socket 比较重要; 而default-character-set 是mysql 自己认识的,而mariadb5.5 就不认识,相当于变成了character_set_server6. 创建慢查询日志文件既然上面指定了慢查询日志文件,而MariaDB又不会自己创建该文件。
所以我们需要自己创建,并修改相应的文件权限(比如mysql采用mysql用户,可能我们使用root用户创建文件,此时要求慢查询文件对mysql用户可以读也可以写)[root@localhost etc]# touch /usr/local/iternal/mysql_data/slow_query_log.log[root@localhost etc]# chmod 666 /usr/local/iternal/mysql_data/slow_query_log.log 7.重新启动Mariadb服务[root@localhost etc]# systemctl start mysql.service。
数据库日志文件过大的处理方法
当数据库日志文件过大时,可以采取以下处理方法:
1. 增加日志文件的大小限制:可以通过修改数据库的配置参数来增加日志文件的大小限制,例如增加每种类型日志文件的最大大小限制,或者增加整个日志文件组的最大大小限制。
2. 压缩或归档日志文件:可以通过压缩或归档数据库的日志文件来减小其占用的磁盘空间。
可以使用压缩工具,例如gzip
或7-Zip等,来对日志文件进行压缩。
或者可以将已经归档的
日志文件移到其他存储介质,例如磁带库或远程备份服务器上。
3. 定期清理日志文件:可以定期清理数据库的日志文件,删除不再需要的旧日志。
可以设置一个保留期限,例如保留最近一周或一个月的日志文件,然后定期删除超过保留期限的日志文件。
4. 增加日志文件的切割频率:可以通过增加日志文件的切割频率来减小单个日志文件的大小。
可以将一个较大的日志文件切割成多个较小的日志文件,每个文件都包含一段时间范围内的日志。
5. 导出日志数据到其他存储介质:可以将数据库的日志数据导出到其他存储介质,例如分布式文件系统或集中式日志服务器上。
这样可以减小数据库的日志文件大小,同时还可以方便地对日志数据进行分析和检索。
需要注意的是,在处理数据库日志文件过大时,要确保同时满足数据库的恢复和故障恢复要求。
因此,在实施上述处理方法之前,应该详细了解数据库管理系统的日志管理机制,并根据具体情况进行操作。
达梦数据库操作手册work Information Technology Company.2020YEAR达梦数据库操作手册2013年12月15日达梦数据库安装一、服务器安装1.1 数据库安装注意问题数据库的安装路径不要直接放在操作系统的/目录相同的磁盘上,可以安装在/dmdb/dm,但是/dmdb要单独挂载在一块硬盘上。
根据业务需要及数据量,数据文件放在磁盘空间较大的分区下。
1.2 安装步骤1.2.1 图形化界面安装1. 为DMInstall.bin赋予可执行权限chmod +x DMInstall.bin2. 运行DMInstall.bin,进行数据库安装./DMInstall.bin3. 接受安装许可协议4. 查看版本信息5. 选择安装的key文件6. 选择安装类型7. 选择安装路径,及勾选高级配置选项8. 进行高级选项数据库配置,页大小32K,簇大小16页,大小写敏感->“是”,UNICODE字符集->“否”,空串‘’按NULL处理->“是”9. 修改系统管理员密码,此处不需要修改10. 开始菜单文件夹建立11. 完成安装配置,显示安装小结12. 完成安装,修改安装目录下dm.ini文件中的部分参数,详见1.2.3节内容。
1.2.2字符形式安装某些情况下,无法使用图形话界面连接到服务器上,此时安装达梦数据库可以使用字符界面安装。
1.运行达梦安装文件./DMInstall.bin -i如果提示权限不够,进行授权,执行:chmod+xDMInstall.bin2. 开始安装,根据提示输入dm.key所在位置方括号内为key文件所在位置默认路径,回车选择默认路径。
3.选择安装类型选择Typical,输入1。
4. 选择安装路径例如,将达梦安装在/dmdb/dm,输入路径。
5.确认安装路径输入Y(或y)。
6. 选择初始化数据库输入Y(或y)确定初始化数据库。
7. 选择不安装实例数据库输入N。
Oracle 改变数据文件名称和位置在建立数据文件之后,还可以改变它们的名称或位置。
通过重命名或移动数据文件,可以在不改变数据库逻辑结构的情况下对数据库的物理存储结构进行调整。
改变数据文件的操作分为两种情况:要改变的数据文件属于同一个表空间;要改变的数据文件分别属于多个表空间。
在这两种情况下,分别需要使用不同的语句进行操作。
1.改变属于单独表空间的数据文件如果要改变属于某一个表空间的数据文件的名称和位置,则可以按照如下步骤进行:(1)将包含数据文件的表空间设置为脱机状态。
将表空间设置为脱机状态是为了关闭该表空间所有的数据文件。
SQL> alter tablespace user01 offline normal;表空间已更改。
(2)在操作系统中重新命名或移动数据文件。
(3)在ALTER TABLESPACE 语句中使用RENAME FILE 子句,在数据库内部修改数据文件的名称。
例如,在操作系统中将数据文件USER01_01.DBF 和USER01_02.DBF 从D:\ORACLEDATA\目录中称动到E:\ORADATA\ORCL\目录下,则可以使用如下的语句在数据库内部修改数据文件的位置: SQL> alter database2 rename file3 'd:\oracledata\user01_01.dbf',4 'd:\oracledata\user01_02.dbf'5 to6 'e:\oradata\orcl\user01_01.dbf',7 'e:\oradata\orcl\user01_02.dbf';数据库已更改。
TO 子句后指定的数据文件必须已经存在,ALTER TABLESPACE 语句实际上并不会创建这些数据文件。
另外,在语句必须提供完整的文件路径和名称并指向正确的操作系统文件。
(4)重新将表空间设置为联机状态。
idea的git日志修改方法
要修改idea中的git日志,你可以按照以下步骤进行操作:
1. 打开IntelliJ IDEA,并进入你的项目。
2. 在IDEA的右下角,你会看到一个“Version Control”按钮,
点击它打开Version Control工具窗口。
3. 在Version Control工具窗口中,选择“Log”选项卡,这
样你就可以看到你的项目的git日志了。
4. 找到你想要修改的提交记录,右键点击该提交记录,然后选
择“Interactively Rebase from Here”选项。
5. 在弹出的对话框中,你可以看到所有的提交记录,你可以选
择要修改的提交记录,并在弹出的对话框中选择“Edit”选项。
6. 在弹出的编辑提交信息的对话框中,你可以修改提交信息,
然后点击“Amend”按钮来保存修改。
7. 修改完提交信息后,你可以继续进行rebase操作,或者点
击“Apply”按钮来应用这些修改。
通过上述步骤,你就可以在IntelliJ IDEA中修改git日志了。
记住,在修改提交记录时要小心谨慎,确保不会对你的项目造成不
良影响。
Oracle数据库⽂件路径变更环境:RHEL 6.4 + Oracle 11.2.0.3情景⼀:只是部分普通数据⽂件迁移,可以在线操作。
1.将对应表空间offline,移动数据⽂件到新路径2.数据⽂件alter database rename file '' to '';3.再将表空间online情景⼆:所有数据⽂件迁移。
本⽂是针对情景⼆的实验,需求:主机/oradata挂节点变更为/usr2.在/usr2建⽴oradata⽂件夹来存放之前/oradata的所有⽂件。
操作步骤:1.查看当前数据库的数据⽂件,临时⽂件,⽇志⽂件,控制⽂件,参数⽂件等信息。
2.根据当前spfile创建pfile⽂件,正常关闭数据库,移动源数据库⽂件到新的存储路径。
3.修改数据库参数⽂件,更改控制⽂件路径为新的存储路径,⽤改好的pfile⽂件启动数据库到mount状态。
4.重定向数据库的所有数据⽂件、⽇志⽂件路径,然后正常打开数据库。
5.核查各⽂件路径没有问题,根据当前pfile创建spfile,重启数据库实例。
1.查看当前数据库的数据⽂件,临时⽂件,⽇志⽂件,控制⽂件,参数⽂件等信息。
SQL>select name from v$datafile;NAME--------------------------------------------------------------------------------/oradata/sysdata/jingyu/system01.dbf/oradata/sysdata/jingyu/sysaux01.dbf/oradata/sysdata/jingyu/undotbs01.dbf/oradata/sysdata/jingyu/users01.dbfSQL>select name from v$tempfile;NAME--------------------------------------------------------------------------------/oradata/sysdata/jingyu/temp01.dbfSQL>select member from v$logfile;MEMBER--------------------------------------------------------------------------------/oradata/sysdata/jingyu/redo03.log/oradata/sysdata/jingyu/redo02.log/oradata/sysdata/jingyu/redo01.logSQL>select name from v$controlfile;NAME--------------------------------------------------------------------------------/oradata/sysdata/jingyu/control01.ctl/opt/app/oracle/fast_recovery_area/jingyu/control02.ctlSQL> show parameter pfileNAME TYPE VALUE------------------------------------ ----------- ------------------------------spfile string /opt/app/oracle/product/11.2.0/dbhome_1/dbs/spfilejingyu.ora2.根据当前spfile创建pfile⽂件,正常关闭数据库,移动源数据库⽂件到新的存储路径。
LogMiner用法一、概述LogMiner是由Oracle提供的一款用于分析和恢复数据库中的事务日志的工具。
它能够解析数据库的归档日志和在线日志,并提供对事务数据的查询和分析功能。
本文将介绍LogMiner的使用方法以及一些常见的应用场景。
二、LogMiner的安装与配置1. 安装Oracle数据库并确保数据库启用了归档功能。
2. 配置LogMiner的参数,包括指定归档日志和在线日志的存储位置以及日志文件的格式等。
3. 在数据库中创建适当的目录对象,用于存储LogMiner的相关文件。
三、LogMiner的基本用法1. 启动LogMiner$ sqlplus / as sysdbaSQL> EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);2. 加载需要分析的日志文件SQL> EXECUTEDBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME =>'/path/to/archived_log_file1', OPTIONS => DBMS_LOGMNR.NEW);SQL> EXECUTEDBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME =>'/path/to/archived_log_file2', OPTIONS => DBMS_LOGMNR.ADDFILE);3. 执行数据查询SQL> SELECT username, operation, table_name, sql_redo FROMv$logmnr_contents;四、LogMiner的应用场景1. 数据恢复当数据库发生故障或误操作导致数据丢失时,可以使用LogMiner 分析事务日志,找回被删除或修改的数据。
SQL修改数据库存放路径USE masterGO--创建测试的数据库CREATE DATABASE SalesON ( NAME = Sales_dat,FILENAME = 'c:\saledat.mdf ') LOG ON( NAME = 'Sales_log ',FILENAME = 'c:\salelog.ldf ') go --显示创建的数据库的文件位置selectname,filename from Sales..sysfiles/*--查询结果:name filename-------------- ------------------Sales_dat c:\saledat.mdfSales_log c:\salelog.ldf(所影响的行数为 2 行)go--备份数据库backup database Sales to disk= 'c:\Sales.bak ' with init go--还原Sales 并指定数据文件及日志文件的位置restore database Sales from disk= 'c:\Sales.bak 'with move 'Sales_dat ' to 'd:\saledat.mdf ',move 'Sales_log ' to 'd:\salelog.ldf ',replacego--显示还原后数据库的文件位置selectname,filename from Sales..sysfiles/*--测试结果(可以看出,数据文件位置是变了)name filename-------------- ----------------------Sales_dat d:\saledat.mdfSales_log d:\salelog.ldf(所影响的行数为 2 行)--*/go--删除测试的数据库drop database Sales测试移动msdb这个库的.USE masterGO--显示创建的数据库的文件位置selectname,filename from msdb..sysfiles/*--查询结果:name filename------------ ----------------------------------------------------------------MSDBData d:\Program Files\Microsoft SQL Server\MSSQL\data\msdbdata.mdfMSDBLog d:\Program Files\Microsoft SQL Server\MSSQL\data\msdblog.ldf(所影响的行数为 2 行)--*/go--备份数据库backup database msdb to disk= 'c:\msdb.bak ' with initgo--还原Sales 并指定数据文件及日志文件的位置restore database msdb from disk= 'c:\msdb.bak 'with move 'MSDBData ' to 'c:\msdbdata.mdf ',move 'MSDBLog ' to 'c:\msdblog.ldf ',replacego--显示还原后数据库的文件位置selectname,filename from msdb..sysfiles/*--测试结果(可以看出,数据文件位置是变了)name filename-------------- ----------------------MSDBData c:\msdbdata.mdfMSDBLog c:\msdblog.ldf(所影响的行数为 2 行)--*/Go1)转移master数据库。
【干货分享】DM7中log_commit.log日志文件存储路径
的修改方式
在DM7中,log_commit.log文件用于记录数据库接收到的所有SQL语句等信
息,DBA可以通过分析该文件来帮助解决问题。要生成该文件,只需将配置文
件dm.ini中的参数SVR_LOG设置为1,即启用SVR_LOG就可以了。
log_commit.log默认存储在与bin目录同级的log目录下。但是在读写频繁的
生产环境中,存储为默认路径可能会有如下问题发生:
1、dmp或bak文件未及时清理,累积造成磁盘空间不足,导致log_commit
日志无法正常存储,从而使数据库无法被正常访问。
2、存储足够数量的log_commit.log文件,会更加利于DBA对数据库业务运行
状态进行分析,但难免出现为了保证磁盘空间而减少对log_commit.log文件存
储数量的情况。
尽早更换该日志文件的存储路径,就可以很好的避免陷入上述两难的窘境。
当然,上述问题未必一定发生,但是生产环境中未雨绸缪总还是好些。何况,修
改方法非常简单。按如下三步:
步骤1:检查。
确保dm.ini中SVR_LOG=1,且有SVR_LOG_NAME参数及对应参数值,及log
目录下有sqllog.ini文件:
图 1 查看dm.ini
图 2 sqllog.ini文件参考内容
步骤2:修改。
在SQL日志的配置文件sqllog.ini中修改:
FILE_PATH = 指定log_commit存储路径
比如:
图 3
文件sqllog.ini用于SQL日志的配置。当把dm.ini中参数SVR_LOG置为1
(图
1)
,才会打开SQL日志。
步骤3:使配置生效。
如果在服务器启动过程中,修改了sqllog.ini文件。修改之后的文件,只要调用
过程SP_REFRESH_SVR_LOG_CONFIG() 就会生效。如下:
图 4 执行过程
最后可以执行任意查询语句,确认一下日志的生成情况。
图 5 查看日志生成情况
通过简单的检查、修改、使配置生效三步就可以修改log_commit.log日志文件
存储路径的修改。
关于对log_commit.log日志文件的存储内容、个数、大小进行配置的方法,基
本都是在配置文件中增加相应配置项,具体可以参考《DM7系统管理员手册》。