相关疑难解决方法(0)

您好，我正在运行最新版本的 Percona Server。

服务器版本：5.5.24-55 Percona Server (GPL)，26.0 版

我有一个10个cpu的盒子有这些特点。

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 9
model name      : AMD Opteron(tm) Processor 6128
stepping        : 1
microcode       : 0x10000d9
cpu MHz         : 800.000
cache size      : 512 KB

它具有 SSD 和 64GB 的 RAM。Innodb 大约为 10GB，因此 innodb_buffer_pool_size 设置为 10GB。

我有一张如下表：

create table TODAY
( symbol_id       integer not null
, openp           decimal(10,4)
, high            decimal(10,4)
, low             decimal(10,4)
, last            decimal(10,4) not null
, volume …

自从我们迁移到 Amazon RDS 以来，我们遇到了一些非常疯狂的性能问题，今天我们开始遇到锁定问题。正因为如此，我认为这只是一个超时问题，并去检查我们使用的内存。我们交换了大约 70MB 的数据。我用 mysqltuner 进行了一次内存追捕，它说可能有大约 400% 的最大内存使用率。多亏了 Percona 的配置向导，我现在把它降到了 100% 以上。

但是，我们仍然有这个锁问题，所以我假设它与内存/交换无关。为什么我仍然收到锁定？这里发生了什么？

我相信重新启动将解决问题，但这不应该是解决方案。我们可以做些什么来防止将来发生这种情况？我尝试刷新查询缓存和表 - 有效。

由于 RDS，其他类型的冲洗不起作用：/

以下是我可以提供的大量信息：

询问

INSERT INTO `myTable` (`firstName`, `lastName`, `email`) VALUES ('Travis', 'B...', '...@gmail.com')

错误信息

Lock wait timeout exceeded; try restarting transaction

表模式

CREATE TABLE IF NOT EXISTS `myTable` (
  `id` int(15) NOT NULL AUTO_INCREMENT,
  `firstName` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `lastName` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `email` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

  PRIMARY KEY (`id`),
  UNIQUE KEY `Unique Emails` (`email`),
  KEY …

我查看了 my.ini 并看到了各种默认设置。我的数据库在一台独立的 PC 上运行。我想总体上优化 InnoDB 和 MySQL 的性能以提高性能。没有磁盘空间限制。我应该更改哪些默认设置以优化以获得更好的性能、可靠性和可能的​​时间点备份 [高可用性]。

已编辑

目前，每当我通过 MySQL Administrator 上的维护运行“优化表”时，它都会显示：

表不支持优化，改为重新创建+分析

在所有桌子上。我所有的表都是InnoDB，但为什么不支持Optimize？

好吧，这可能是三个问题。我想将使用 MyISAM 的现有 MySQL 5.1 数据库移动到使用 InnoDB 的 5.6，因为我认为有很多明显的 - 甚至可能是好的 - 原因。

这是在 Amazon RDS 上，所以我的升级路线仅限于转储和重新创建数据库。

我会欣然承认我不是一个老练的 DBA。

问题 1：哇这么慢！

大约需要 15 分钟 mysqldump我们的 1.6 亿多行。（表演桌等来了，抱紧你的马。）

花了大约 50 个小时加载到 mysql 5.6 实例中，并且引擎巧妙地将 sed-script-ed 加载到 InnoDB。

问题 2：我的行在哪里？

select count(*) from node;在目前的 DB 上给出了大约 1.62 亿。在5.6上，它给出了大约9300万。加载似乎是成功的，尽管我无法证明；至少，加载终止后没有错误消息。

如果它不成功，那真的慢。

问题 3：哇这么慢！

因此，select count(*) from node;在 5.1 上几乎没有任何时间完成——查询结果在 0.00 到 0.03 秒之间。在使用 InnoDB 的 5.6 上，这需要一分钟多的时间。解释清楚地表明这是因为查询优化的方式不同——但不清楚为什么不同。

表格和说明

MySQL 5.1

mysql> show …

由于我们的初创公司发展顺利，我们现在遇到了一些您一直认为永远不会影响您的问题。

我们已经扩展了很多应用程序堆栈：我们将临时信息的高读/写表卸载到一个单独的 Percona 服务器，其中表以“Engine=MEMORY”运行，并将其他部分迁移到 cassandra 集群。

现在我们剩下一个“精益”数据库，其中我们的读/写负载为 88%/12%。在这一点上，我有几个问题想得到一些反馈：

1. 读奴隶

通过我们的读/写设置，一些（例如 2-3 个）读从站应该将我们的写主站上的读负载减少到最低限度。read-slave 解决方案的可扩展性如何：如果我们的负载增加一倍/三倍，我们的负载是添加额外的 read slaves 将继续为读取提供足够的容量？我阅读了这篇文章：每个主人的奴隶数量有什么限制？然而，不是出于可扩展性背景，这可能看起来很愚蠢，但这是一个可冻结的解决方案吗？有很多人在推动分片而不是读从解决方案，但是，我现在真的认为我们的读/写负载不需要重写我们应用程序的大部分......有什么想法吗？

2. 多数据中心和复制

此外，我们正在考虑为附近的数据中心提供服务，以减少网络延迟（我们处理不喜欢延迟的移动应用程序）。计划是使用很多提到的半同步。复制（见：这是个好主意，MySQL数据库分成两个服务器，并为MySQL复制的高延迟互连是否受影响？）的主-主复制，其中每个数据中心都有一个主，和多个读的奴隶。同样，天真地，我很想知道在扩展时这是否在“最佳实践”的范围内。

3. 硬件和配置

过去几周我一直忙于对我们的实时系统进行基准测试，我得出的结论是，无论我们为第 1 点和第 2 点选择哪种解决方案，我们当前使用的服务器都不会运行很长时间，是否可以我对我们的设置有一些想法：

CPU: Intel(R) Xeon(R) CPU E31275 @ 3.40GHz mit 8 cores (hyperthreading)
RAM: 16GB
Raid 10 with a strip size of 64 KB and controller cache enabled
Software: Percona 5.5
Database size: 83.7GB
Top 5 Tables:
 21302MB  table1
 7656MB  table2
 5477MB  table3
 4352MB  table4
 3663MB  table5

my.cnf 设置： …

看起来我们的数据库服务器正在以越来越快的速度进行垃圾收集，这看起来很正常，因为它在增长。什么时候切换到更大的实例有什么好的经验法则，我不是 DBA，也没有参考框架。现在每当只剩下 100mb 时，它似乎每 2-3 天进行一次垃圾收集。

服务器本身有 1.7GB 的 RAM。