2017年8月

Nginx配置url重写

url重写是指通过配置conf文件,以让web的url中达到某种状态时则定向/跳转到某个规则,比如常见的伪静态、301重定向、浏览器定向等等
rewrite
语法
在配置文件的server块中写,如:

server {
    rewrite 规则 定向路径 重写类型;
}

规则:可以是字符串或者正则来表示想匹配的目标url
定向路径:表示匹配到规则后要定向的路径,如果规则里有正则,则可以使用$index来表示正则里的捕获分组
重写类型:
last :相当于Apache里德(L)标记,表示完成rewrite,浏览器地址栏URL地址不变
break;本条规则匹配完成后,终止匹配,不再匹配后面的规则,浏览器地址栏URL地址不变
redirect:返回302临时重定向,浏览器地址会显示跳转后的URL地址
permanent:返回301永久重定向,浏览器地址栏会显示跳转后的URL地址










---阅读剩余部分---

Nginx使用proxy_pass及rewrite使用二级目录请求

实现效果:访问http://www.abc.com/artH5目录,即可请求到http://192.168.120.241:8080的内容,nginx上添加如下配置:

location ~* ^/artH5.*$ {
include deny.conf;
rewrite ^/artH5/(.*) /$1 break;    #处理artH5多余的路由,实现根目录请求源地址效果
proxy_pass http://192.168.120.241:8080;
include proxy.conf;
error_log  logs/artH5_error.log info;
access_log  logs/artH5_access.log  main;
}

reload即可;
nginx更多说明参考:
https://xuexb.com/post/nginx-url-rewrite.html
http://seanlook.com/2015/05/17/nginx-location-rewrite

Linux设置HugePages操作记录

当大量内存用于 Oracle 数据库时,操作系统将消耗大量资源来管理虚拟地址到物理地址转换,其结果往往是一个非常大的页表结构。由于每条页表条目包含进程正在使用的所有内存页面的虚拟地址到物理地址的转换,因此对于非常大的系统全局区 (SGA),每个进程的页表条目都可能很大。例如,使用 8 GB 内存的 Oracle 数据库进程的页表条目将达 8 GB/4 KB(即 2097152 条记录或页面)。如果有 100 个 Oracle 数据库会话/进程,则将页面数乘以 100。您可以看到,要管理的页面数量巨大。

通过在 Linux 中启用 HugePages,可以通过增大页面大小来减少 TLB 条目数。对于 Linux,HugePages 大小为 2 MB。通过为 Oracle 数据库 SGA 选用更大的页面,可大大减少要管理的页面数。

注:启用 HugePages 可显著提升性能。

透明 HugePages 和 Oracle 数据库

最近,RHEL 6、Oracle Linux 6 和 SUSE Linux Enterprise Server 11 中引入了一个新特性 — 透明 HugePages。透明 HugePages 旨在自动、动态地利用 HugePages。遗憾的是,目前透明 HugePages 与传统 HugePages 联用会出现一些问题,导致性能问题和系统重启。在 My Oracle Support 说明 1557478.11557478.1 中,Oracle 建议不要同时使用透明 HugePages 和 Oracle 数据库。
注:在 Oracle Linux 6.5 版中,已删除透明 HugePages。

验证是否已对 Oracle 数据库实例启用大页面

可以通过检查警报日志来验证是否对数据库实例启用了大页面。启动实例时,您应在警报日志中参数列表前面看到如下内容:

Large Pages Information *
Total Shared Global Region in Large Pages = 28 GB (100%)
Large Pages used by this instance: 14497 (28 GB)
Large Pages unused system wide = 1015 (2030 MB) (alloc incr 64 MB)
Large Pages configured system wide = 19680 (38 GB)
Large Page size = 2048 KB
参考http://www.oracle.com/technetwork/cn/articles/servers-storage-dev/hugepages-2099009-zhs.html

Linux设置HugePages操作记录步骤如下:

1、查看当前系统是否配值HugePages

下面的查询中HugePages相关的几个值都为0,表明当前未配值HugePages,其次可以看到Hugepagesize为2MB。

[root@hch_test_pd_121_217 ~]$grep Huge /proc/meminfo
AnonHugePages:   5787648 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

2、修改用户的memlock限制

通过修改/etc/security/limits.conf 配值文件来实现
该参数的值通常配值位略小于当前的已安装系统内存,如当前你的系统内存为64GB,可以做如下设置

  • soft memlock 60397977
  • hard memlock 60397977
    上述的设置单位为kb,不会降低系统性能。至少也要配值为略大于系统上所有SGA的总和。

使用ulimit -l 来校验该设置

3、禁用AMM(oracle 11g)

如果当前的Oracle 版本为10g,可以跳过此步骤。
如果当前的Oracle 版本为11g,由于AMM(Automatic Memory Management)特性与Hugepages不兼容,需要禁用AMM:

    ALTER SYSTEM RESET memory_target SCOPE=SPFILE;
    ALTER SYSTEM RESET memory_max_target SCOPE=SPFILE;
    ALTER SYSTEM SET sga_target=<n>g SCOPE=SPFILE;
    ALTER SYSTEM SET pga_aggregate_target=<n>g SCOPE=SPFILE;
    SHUTDOWN IMMEDIATE; 
    STARTUP;

4、计算vm.nr_hugepages 的值

使用Oracle 提供的脚本hugepages_settings.sh的脚本来计算vm.nr_hugepages的值
在执行脚本之前确保所有的Oracle 实例已启动以及ASM也启动(存在的情形下)
sh hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 14467
手工计算:
nr_hugepages>=SGA_Target/Hugepagesize
=16G*1024M/2M
=4608

vim /etc/sysctl.conf 来设置vm.nr_hugepages参数

vm.nr_hugepages = 1496  
sysctl -p     #执行生效

5、停止所有的Instance并重启server

上述的所有步骤已经实现了动态修改,但对于HugePages的分配需要重新启动server才能生效。

6、验证配值

HugePages相关参数的值会随着当前服务器上的实例的停止与启动而动态发生变化
通常情况下,HugePages_Free的值应当小于HugePages_Total的值,在HugePages被使用时HugePages_Rsvd值应当为非零值。

 [root@c69160 ~]$ grep Huge /proc/meminfo
  HugePages_Total:   131
  HugePages_Free:     20
  HugePages_Rsvd:     20
  Hugepagesize:     2048 kB 
 如下面的情形,当服务器上仅有的一个实例被关闭后,HugePages_Rsvd的值为零。且HugePages_Free等于HugePages_Total
  $ grep Huge /proc/meminfo
  HugePages_Total:   131
  HugePages_Free:    131
  HugePages_Rsvd:      0
  Hugepagesize:     2048 kB   

#### 下面的三种情形应当重新配置HugePages
    1、物理内存的增减或减少
    2、在当前服务器上新增或移出Instance
    3、Instance的SGA大小增加或减少   
#### 如果未能调整HugePages,可能会引发下面的问题
    1、数据库性能地下
    2、出现内存不足或者过度使用交换空间
    3、数据库实例不能被启动

Hugepages参数说明及使用注意事项

Hugepages是从Linux kernal 2.6后被引入的,其目的是使用更大的memory page size以适应越来越大的系统内存,使用hugepage可以用更大的内存页来取代传统的4K页面。

page table

page table是操作系统上的虚拟内存系统的数据结构模型,用于存储虚拟地址与物理地址的对应关系。
当我们访问内存时,首先访问page table,然后Linux在通过page table的mapping来访问真实物理内存(ram+swap)

TLB

A Translation Lookaside Buffer (TLB)
TLB是在cpu中分配的一个固定大小的buffer(or cache),用于保存page table的部分内容,使CPU更快的访问并进行地址转换。

hugetlb

hugetlb 是记录在TLB 中的条目并指向Hugepages。

hugetlbfs

这是一个新的基于2.6 kernel之上的内存文件系统,如同tmpfs。
在TLB中通过hugetlb来指向hugepage。这些被分配的hugepage作为内存文件系统hugetlbfs(类似tmpfs)提供给进程使用。

HugePage主要带来以下好处:

1、HugePages 会在系统启动时,直接分配并保留对应大小的内存区域。
2、HugePages 在开机之后,如果没有管理员的介入,是不会释放和改变的。
3、没有swap。
Notswappable: HugePages are not swappable. Therefore thereis no page-in/page-outmechanism overhead.HugePages are universally regarded aspinned.







---阅读剩余部分---

Oracle用户密码含特殊字符时的登陆设置

当Oracle数据库用户的密码含特殊字符如 @ 时,直接使用正常的密码输入,由于oracle将@后的字符解析为网络服务名而导致登陆失败

如下演示 用户名为:wang密码为:oracle@1网络服务名为:sun 的情况:

Linux平台

'wang/"oracle@1"'@sun    --1个双引号扩密码,1个单引号扩 用户名+密码,即: '用户名/"密码"'@服务名
$sqlplus 'wang/"oracle@1"'@sun
SQL*Plus: Release 11.2.0.1.0 Production on Tue Oct 30 11:42:25 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the OLAP and Data Mining options

wang@SUN>

---阅读剩余部分---

Oracle11g安装界面中文乱码解决方法

在Linux的X window桌面里安装oracle,弹出的oracle界面为乱码(方块)原因:oracle安装默认没有中文语言包,只有用英文,但是系统设置的默认语言是zh_cn.UTF-8,所以会出现方块乱码,切换到root账号,执行

export LANG=en_US
vim /etc/sysconfig/i18n
LANG="en_US"(不会出现乱码)
LANG="zh_cn.UTF-8"(中文,安装oracle会出现界面乱码的现象)

切还到oracle账号,继续安装即可.

Azure安装gnome桌面NetworkManager-0.8.1-66.el6.x86_64报错解决

Azure下的Linux在安装GNOME桌面及VNC的时候,会有

--> Finished Dependency Resolution

Error: WALinuxAgent conflicts with 1:NetworkManager-0.8.1-66.el6.x86_64
You could try using --skip-broken to work around the problem
** Found 4 pre-existing rpmdb problem(s), 'yum check' output follows:

或者类似错误,直接带上--skip-broken参数就可以了:

yum --skip-broken groupinstall "GNOME Desktop" "Graphical Administration Tools" -y
yum --skip-broken groupinstall "X Window System" "Desktop" -y

参考:https://blogs.msdn.microsoft.com/faber/2014/10/16/how-to-install-vnc-in-azure-oracle-linux-vm/

MySQLdump 使用 --set-gtid-purged参数

1.导出时指定字符集,报错Character set 'utf-8' is not a compiled character set and is not specifie .
--default-character-set=utf-8

这个是因为字符集错了。是--default-character-set=utf8
2,导出时提示warning,A partial dump from a server that has GTIDs

[root@localhost data]# mysqldump -uroot --master-data=2 -p --single-transaction --databases test >3.sql
Enter password:
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.

关于GTID是5.6以后,加入了全局事务 ID (GTID) 来强化数据库的主备一致性,故障恢复,以及容错能力。
官方给的:A global transaction identifier (GTID) is a unique identifier created and associated with each transaction committed on the server of origin (master).
所以可能是因为在一个数据库里面唯一,但是当导入其他的库就有可能重复。所有会有一个提醒。

可以通过添加--set-gtid-purged=off 或者–gtid-mode=OFF这两个参数设置。
例如:导出langold_enroment库中FIN_INCOME表的数据和结构:

/usr/local/mysql/bin/mysqldump --user=root --host=localhost --default-character-set=utf8 --socket=/data/mysql/mysql.sock -p'xxxxxx' --extended-insert=false --set-gtid-purged=off langold_enroment FIN_INCOME > /tmp/FIN_INCOME.sql

Linux crontab配置文件

cron程序是 Linux 下计划任务,就是在约定的时间执行已经计划好的工作。我们可以把 crond 设置为开机时自动启动,crond 启动后,它会读取配置文件(全局性配置文件/etc/crontab,以及用户的配置文件),然后 crond 会根据命令和执行时间来按时来调用度工作任务。crond 程序默认开机启动,如果没有启动,可以运行 【/etc/init.d/cron start】 命令手动运行。 cron 还有一个配置工具 crontab 命令,用来读取和编辑计划任务的。

---阅读剩余部分---

MySQL聚合函数GROUP_CONCAT()实现合并多个记录

语法如下:
group_concat([DISTINCT] 要连接的字段 [Order BY ASC/DESC 排序字段] [Separator '分隔符'])
一般配合group by 一起使用。
举例:
以id分组,把name字段的值打印在一行,逗号分隔(默认)

mysql> select id,group_concat(name) from aa group by id;
+------+--------------------+
| id| group_concat(name) |
+------+--------------------+
|1 | 10,20,20|
|2 | 20 |
|3 | 200,500|
+------+--------------------+
3 rows in set (0.00 sec)

以id分组,把name字段的值打印在一行,分号分隔

mysql> select id,group_concat(name separator ';') fromaa group by id;
+------+----------------------------------+
| id| group_concat(name separator ';') |
+------+----------------------------------+
|1 | 10;20;20 |
|2 | 20|
|3 | 200;500 |
+------+----------------------------------+
3 rows in set (0.00 sec)

以id分组,把去冗余的name字段的值打印在一行,逗号分隔

mysql>select id,group_concat(distinct name) from aa group by id;
+------+-----------------------------+
| id| group_concat(distinct name) |
+------+-----------------------------+
|1 | 10,20|
|2 | 20 |
|3 | 200,500 |
+------+-----------------------------+
3 rows in set (0.00 sec)

以id分组,把name字段的值打印在一行,逗号分隔,以name排倒序

mysql> select id,group_concat(name order by name desc)from aa group by id;
+------+---------------------------------------+
| id| group_concat(name order by name desc) |
+------+---------------------------------------+
|1 | 20,20,10 |
|2 | 20|
|3 | 500,200|
+------+---------------------------------------+
3 rows in set (0.00 sec)

MySQL查询重复记录、删除重复记录方法

1、查找全部重复记录

Select * From 表 Where 重复字段 In (Select 重复字段 From 表 Group By 重复字段 Having Count(*)>1)  

2、过滤重复记录(只显示一条)

Select * From 表 Where ID In (Select Max(ID) From 表 Group By Title)     #显示ID最大一条记录

3、删除全部重复记录

Delete 表 Where 重复字段 In (Select 重复字段 From 表 Group By 重复字段 Having Count(*)>1)  

4、删除全部重复记录保留最大ID最大一条记录

Delete 表 Where ID Not In (Select Max(ID) From 表 Group By Title)    #保留ID最大一条记录

---阅读剩余部分---

binlog开启与删除及参数说明

MySQL Server 有四种类型的日志——Error Log、General Query Log、Binary Log 和 Slow Query Log。

Error Log:错误日志,记录 mysqld 的一些错误。
General Query Log:一般查询日志,记录 mysqld 正在做的事情,比如客户端的连接和断开、来自客户端每条 Sql Statement 记录信息;如果你想准确知道客户端到底传了什么给服务端,这个日志就非常管用了,不过它非常影响性能。
Binary Log:就是Binlog 了,包含了事件,这些事件描述了数据库的改动,如建表、数据改动等,也包括一些潜在改动,比如DELETE FROM ran WHERE bing = luan,然而一条数据都没被删掉的这种情况。除非使用 Row-based logging,否则会包含所有改动数据的 SQL Statement,Binlog 就有了两个重要的用途——复制和恢复。
Slow Query Log:慢查询日志,记录一些查询比较慢的 SQL 语句——这种日志非常常用,主要是调优用的。

启用 Binlog

通常情况 MySQL 是默认关闭 Binlog 的,
log-bin = /data/mysql/binlog/mybinlog #开启binlog
这里的 log-bin 是指以后生成各 Binlog 文件的前缀,比如上述使用mybinlog,那么文件就将会是mybinlog.000001、mybinlog.000002 等。






---阅读剩余部分---

GTID备份恢复注意事项

MySQL工作在GTID模式做备份恢复的时候,有时需要恢复出来的 MySQL 实例可以作为从库连上原来的主库继续复制,这就要求从备份恢复出来的 MySQL 实例拥有和主数据库数据一致的 gtid_executed 值。这也是通过设置 gtid_purged实现的,下面看下 mysqldump 做备份的例子。

通过mysqldump在主库上做一个全量备份
这里使用 --all-databases选项是因为基于 GTID 的复制会记录全部的事务, 所以要构建一个完整的dump备份

/usr/local/mysql/bin/mysqldump --user=root --host=localhost --default-character-set=utf8 --socket=/data/mysql/mysql.sock -p'xxxxxx' --extended-insert=false  --all-databases --single-transaction  --triggers --routines --events > /tmp/alldatabase.sql

在备份的alldatabase.sql中有GTID_PURGED语句

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;

--
-- GTID state at the beginning of the backup 
--

SET @@GLOBAL.GTID_PURGED='91a08937-7b0b-11e7-9575-52540061843d:1-6';

在slave上恢复前需要清空 gtid_executed 变量

reset master;        #清空gtid_executed
source /tmp/alldatabase.sql;  #导入备份

或者

mysql -h127.0.0.1 --user=root -pxxxxxx < /tmp/alldatabase.sql  #导入

此时恢复出的 MySQL 实例的 GTID_EXECUTED 和在主库备份时的一致:
可以直接进行主从同步了·

MySQL主从同步log_slave_updates参数介绍

默认的情况下log_slave_updates参数是关闭的,从服务器从主服务器接收到的更新不记入它的二进制日志。该选项告诉从服务器将其SQL线程执行的更新记入到从服务器自己的二进制日志。为了使该选项生效,还必须用--logs-bin选项启动从服务器以启用二进制日志。如果想要应用链式复制服务器,应使用--logs-slave-updates。例如,可能你想要这样设置:

A -> B -> C

也就是说,A为从服务器B的主服务器,B为从服务器C的主服务器。为了能工作,B必须既为主服务器又为从服务器。你必须用--logs-bin启动A和B以启用二进制日志,并且用--logs-slave-updates选项启动B。

1、从库只开启log-bin功能,不添加log-slave-updates参数,从库从主库复制的数据不会写入log-bin日志文件里。
2、直接向从库写入数据时,是会写入log-bin日志的。
3、开启log-slave-updates参数后,从库从主库复制的数据会写入log-bin日志文件里。这也是该参数的功能。
开启以后可以实现主主同步,切换。

官方文档:https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html

MySQL的replicatin环境中master/slave常用参数

master所有参数

log-bin=mysql-bin
//控制master的是否开启binlog记录功能;二进制文件最好放在单独的目录下,这不但方便优化、更方便维护。重新命名二进制日志很简单,只需要修改[mysqld]里的
log_bin选项,这里有一点需要注意,如下例子:

log_bin=/home/mysql/binlog/binlog.log
[root@localhost ~]# ll /home/mysql/binlog
total 8
-rw-rw---- 1 mysql mysql 98 Mar 7 17:24 binlog.000001
-rw-rw---- 1 mysql mysql 33 Mar 7 17:24 binlog.index
[root@localhost ~]#

从上面的例子可以看到,我要重新调整logbin的路径为"/home/mysql/binlog",但我log_bin的设置却有些不同,这里需要注意两点
1.1).目录的文件夹命名不能有空格
1.2).指定目录时候一定要以*.log结尾,即不能仅仅指定到文件夹的级别,否则在重启mysql时会报错。

server-id=1
//每个server服务的标识,在master/slave环境中,此变量一定要不一样











---阅读剩余部分---

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log报错解决

MySQL5.7.x使用GTID主从同步show slave status时候报错信息如下

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replica'

解决方法如下:
在Master上使用show master status查看 Executed_Gtid_Set的值,
在Slave上执行如下操作:

RESET MASTER;
set global gtid_purged = 'xxxx';                 -- 这里xxxx是Master的Executed_Gtid_Set
start slave;
show slave status\G;

问题解决,一般出现该问题主要是没正常操作binlog或主库宕机等引起gtid发生变化造成的。

 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.', Error_code: 1236

也可用同样的方法解决.

MySQL5.7.18基于GTID的主从复制过程实现

GTID是5.6时加入的,在5.7中被进一步完善,生产环境建议在5.7版本中使用.
GTID全称为Global Transaction Identifiers,全局事务标识符.
GTID的复制完全是基于事务的,每一个事务对应一个GTID.因此事务执行具有唯一ID,
主从复制时,无需再指定POS位置,只要对比ID有没被执行过,并且每个ID仅执行一次.

GTID复制限制:

不支持涉及非事务存储引擎的更新
不支持CREATE TABLE … SELECT语句
不支持针对临时表的操作: CREATE TEMPORARY TABLE和DROP TEMPORARY TABLE
配置tips

notice:主从都需要开启gtid_mode模式.
使用GITD复制模式官方建议使用row复制模式,具有最高性能.
一主多从模式下更能体现出多线程的性能;

MySQL5.7.x编译安装方法,参考https://www.unixso.com/MySQL/Centos7-3-install-MySQL5-7-17.html

Master my.cnf配置片段

[mysqld]
server-id = 1                                #服务器id
gtid_mode = on                                #开启gtid模式
log-bin = /data/mysql/binlog/master-binlog    #开启binlog
enforce_gtid_consistency = 1                #强制gtid一致性,开启后对于特定create table不被支持
log_slave_update = 1                        #开启从库写入binlog
binlog_format = row                            #binlog开启row模式
relay_log_recovery = 1                        #开启中继日志完整性(当slave从库宕机后,假如relay-log损坏了,导致一部分中继日志没有处理,则自动放弃所有未执行的relay-log,并且重新从master上获取日志,这样就保证了relay-log的完整性。)
sync-binlog = 1                                #强制将binlog_cache写入磁盘,一致性要求不高的场景下设置为0可关闭,性能会大幅提速数倍
skip_slave_start = 1                        #使slave在mysql启动时不启动复制进程,使用 start slave启动 








---阅读剩余部分---

MySQL GTID的原理

GTID介绍

GTID是MySQL 5.6的新特性,其全称是Global Transaction Identifier,可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识一个事务。当事务提交时,MySQL Server在写binlog的时候,会先写一个特殊的Binlog Event,类型为GTID_Event,指定下一个事务的GTID,然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog都会传递到从库,从库在执行的时候也是用同样的GTID写binlog,这样主从同步以后,就可通过GTID确定从库同步到的位置了。也就是说,无论是级联情况,还是一主多从情况,都可以通过GTID自动找点儿,而无需像之前那样通过File_name和File_position找点儿了。支持多线程复制(多数据库同时复制才有意义,仅仅复制一个则没有意义)
通常,由于读取较大,主负责数据的写入,从负责的读取,可以有多从。

GTID展现

GTID = server_uuid:transaction_id
server_uuid 来源于 auto.cnf
GTID: 在一组复制中,全局唯一
mysqlreplicate: 快速调入一个从节点,并且成为GTID中的从节点
mysqlrplcheck: 简单的校验,在ha性能时能够检查节点,那些更易用,更完整的提省为主节点
mysqlrplshow:显示发现拓扑结构
mysqlfailover:能够实现,手动或自动实现故障转移,将从节点提升为主节点
mysqlrpladmin: 实现管理调度









---阅读剩余部分---

如何避免ibdata1文件大小暴涨及释放空间

遇到InnoDB的共享表空间文件ibdata1文件大小暴增时,应该如何处理?

1、问题背景

用MySQL/InnoDB的童鞋可能也会有过烦恼,不知道为什么原因,ibdata1文件莫名其妙的增大,不知道该如何让它缩回去,就跟30岁之后男人的肚腩一样,汗啊,可喜可贺的是我的肚腩还没长出来,hoho~

正式开始之前,我们要先知道ibdata1文件是干什么用的。

ibdata1文件是InnoDB存储引擎的共享表空间文件,该文件中主要存储着下面这些数据:

data dictionary
double write buffer
insert buffer/change buffer
rollback segments
undo space
Foreign key constraint system tables
另外,当选项 innodb_file_per_table = 0 时,在ibdata1文件中还需要存储 InnoDB 表数据&索引。ibdata1文件从5.6.7版本开始,默认大小是12MB,而在这之前默认大小是10MB,其相关选项是 innodb_data_file_path,比如我一般是这么设置的:







---阅读剩余部分---

最新

分类

归档

评论

  • 安安: 都是af
  • Liang: 嗯,有点不通顺·
  • 王庭威: “MySQL互为主从...
  • Liang: 贴下编译参数和步骤,...
  • shao3911: 您好,为什么我在编译...
  • aliang: 先看是yum安装还是...
  • aliang: 将原来的nginx安...
  • yen: 3、如果要回滚的话,...
  • yen: 刚好需要升级ngin...
  • 文雨: 一些新的method...

其它