我一直在尝试 GCP 的 SQL 高可用性选项。有没有办法提高故障转移速度？
在 mysql 完全不可用的情况下，通过 UI 尝试手动故障转移实际上需要 5 分钟多的时间。
我正在使用目前可能没有流量的最小的第二代 5.7 实例。
看起来它实际上是在停止和启动实例。我无法理解这是“HA”的一个选项，意味着停机时间最短。
我正在尝试将我的常规日志文件设置为 fifo 命名管道，但出现错误
$ sudo mkfifo -m 0666 general.fifo
mysql> set global general_log_file='/var/log/mysql/dradis/general.fifo';
ERROR 1231 (42000): Variable 'general_log_file' can't be set to the value of '/var/log/mysql/dradis/general.fifo'
mysql> \! ls -l /var/log/mysql/dradis/general.fifo
prw-rw-rw- 1 root root 0 Nov 27 14:27 /var/log/mysql/dradis/general.fifo
我正在运行 5.6.20-68.0-log Percona Server 的版本。
我怎样才能使这项工作？
起始阅读点：https ://www.percona.com/blog/2015/04/29/generated-virtual-columns-in-mysql-5-7-labs/
使用最新的 percona 5.7 运行一些测试，它们似乎运行良好。Explain plans 和 wall time 看起来不错，但我没有看到显示表状态 index_length 或 data_length 有任何差异。
您如何找到使用这些的真正足迹或开销？
与视图不同，它们似乎确实比带书签的选择更快。
我正在尝试为 percona 的 tokudb 引擎评估最新的 tokudb Hotbackup。
此安装在 debian (Ubuntu 14) 下
我能够在没有错误的情况下安装所有软件包，并安装所有基本的 toku 插件。
尝试安装我得到的备用插头
mysql> install plugin tokudb_backup soname 'tokudb_backup.so';
ERROR 1126 (HY000): Can't open shared library '/usr/lib/mysql/plugin/tokudb_backup.so' (errno: 2 /usr/lib/mysql/plugin/tokudb_backup.so: undefined symbol: tokubackup_version_string)
mysql> select @@version;
+-------------+
| @@version |
+-------------+
| 5.6.27-75.0 |
+-------------+
1 row in set (0.00 sec)
mysql> select @@tokudb_version;
+------------------+
| @@tokudb_version |
+------------------+
| 5.6.27-75.0 |
+------------------+
1 row in set (0.00 sec)
*编辑评论：*
该文件确实存在于文件系统中
# ls -l /usr/lib/mysql/plugin/tokudb_backup.so
-rw-r--r-- 1 root root 23736 Nov 3 05:30 /usr/lib/mysql/plugin/tokudb_backup.so
我怎样才能安装这个？
我读过文档说 log_slave_updates 是必需的。这对于一般的促销情况是有意义的。
但是，对于您打算成为永远不会被提升的只读奴隶的东西，这真的仍然需要吗？
使用 TokuDB 我发现，即使在“优化表”之后，例如更改行压缩或其他 DDL，释放的空间反映在文件系统中也需要不确定的时间量。
无论如何，是否有更立即强制执行此操作或以其他方式查看清理是否正在进行或已安排的状态？
我想知道是否有人对将 MyIASM 表从 mysql 5.5 迁移到 5.6 有任何指示，特别是通过 rsync 使用 Percona 构建？
这样安全吗？
我知道我们需要为 InnoDB 表的迁移执行完整的 mysqldump/reload，但我没有看到任何关于两者之间 MyISAM 格式重大变化的注释。
对于需要几天才能用 mysqldump 完成的相当大的 MyISAM 数据库，这会让事情变得更好一些。
我正在设置一个奴隶并做一些表格校验和来检查事情是否正常，然后再让它们生效。
在将奴隶同步到停止点并与预先存在的奴隶进行比较后，我在奴隶上做了一个本地 mysql 校验和表。
两张桌子不同。为了深入研究，我运行了 pt-table-checksum，它报告新旧奴隶没有差异并且行数相同。
为了获得第三种意见，我做了一个 select * into outfile 由 PK 排序并在输出上运行 md5sum。这两者也很匹配。
一个明显的区别是较新的从属运行的是较新的版本（5.5.34 与 5.5.29）；两个 percona 构建。
这个版本的差异是否会导致校验和的差异？如果是这样，这似乎很奇怪，只有两张桌子有几十个。
我最近将一名新成员提升为 mongo 副本集的主要成员。事情似乎顺利运行了几天，并且没有看到任何问题的任何应用程序症状。然而今天偷看 rs.status() 我注意到它列出了 maintenanceMode -7。我不认为这是可能的，因为它是主要的。我无法在文档中找到有关这意味着什么的任何有用信息。
这是什么意思？
{
"_id" : 26,
"name" : "mongohost5:27032",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 106966,
"optime" : Timestamp(1379627877000, 77),
"optimeDate" : ISODate("2013-09-19T21:57:57Z"),
"maintenanceMode" : -7,
"self" : true
}
JDBC API列出了一个 includeThreadNamesAsStatementComment 参数，该参数似乎表明它将在所有查询前加上 Java 线程 ID 。我认为这对于将数据库活动与应用程序日志联系起来很有用。我将它添加到我的资源 URL 中，它似乎只在部分时间工作。
奇怪的是，作为健康检查的一部分，只有应用程序心跳线程会定期对数据库执行 ping 操作。没有一个“真正的”查询被标记。
为什么这不适用于所有查询？
我有两个具有相同架构的表。一个是定期修剪并保持较小的“主”表。另一个是“报告”表，它是所有内容的存档。为简单起见，假设表模式看起来像
create table main_table(
pk int unsigned not null primary key,
value int unsigned
);
create table reporting_table(
pk int unsigned not null primary key,
value int unsigned
);
我有两个触发器，一个是 AFTER INSERT，一个是 AFTER UPDATE，看起来像
create trigger reporting_insert after insert on main_table
for each row
insert into reporting_table (id,value) VALUES
(NEW.id, NEW.value);
create trigger trigger reporting_update after update on main_table
for each row
update reporting_table set
value=NEW.value
where
id=NEW.id;
主表填充有查询，如
insert into main_table values (1,10) on duplicate key update value=value+1;
我的问题是报告表没有捕捉到这个 ODKU +1 的值（它显然正在主表中更新）。
从触发器文档：
一个可能令人困惑的示例是 INSERT INTO ... ON DUPLICATE KEY UPDATE ... 语法：将为每一行激活 BEFORE INSERT 触发器，然后是AFTER INSERT触发器或BEFORE UPDATE 和 AFTER UPDATE触发器，具体取决于关于该行是否存在重复键。
从阅读中我认为它将遵循后一条路径执行任何更新之前/之后的触发器。对 main_table 执行直接 UPDATE 查询确实会导致更改传播到报告表。
我错过了什么？
我遇到了一个问题，似乎是 mysql 5.1s 对 UTF8 字符的限制。
来自http://dev.mysql.com/doc/refman/5.1/en/charset-unicode-utf8.html
Currently, MySQL support for UTF-8 does not include 4-byte sequences.
我们的应用程序正在抛出周期性异常，例如
java.sql.SQLException: Incorrect string value: '\xF4\x80\x82\x8C ...'
最终的解决方案看起来是迁移到支持 UTF-8 > 3 字节的5.5
不幸的是，这不会像在较新的二进制文件下反弹实例那么简单。作为主要版本转储，我们需要进行完整的转储重新加载，这将需要一些计划的停机时间。
以前有没有其他人不得不处理这种情况？有什么好的解决办法吗？
天真的方法似乎是让应用程序搜索并用问号或 � 替换多字节序列。这似乎很老套，对我或开发人员来说不是一个非常可口的选择。
所以我今天搞砸了一周。我正在添加另一对从站，并在新从站上设置与旧从站相同的服务器 ID。
布局有点像
Master
| |
\/ |
oldS |
\/
newS1
|
|
\/
newS2
所以要清楚旧的从站（oldS）和第一个新的从站（newS1）共享相同的服务器ID。
这不是循环复制，所以我希望一切都会好起来的。我不会预料到后果。
警报开始响起 b/c oldS1 开始越来越落后。查看日志目录，它正在制作成千上万的空中继日志。
我停止在 newS1 上工作，这似乎让事情变得清晰，因为 oldS1 停止制作空的中继日志并恢复。
直到我停止在 newS1 上工作时，两个奴隶似乎都处于一致的状态。
- 修复所有问题是否会像使用新的、唯一的 ID 弹回 newS1 一样简单，尤其是考虑到 newS1 本身是从属于 newS2 的？
- 还有什么需要注意的吗？
- 为什么这会导致 oldS 在清空中继日志后生成空中继日志？我本来希望 oldS 和 newS1 不知道其他人的存在。
- 我认为中继日志滚动只是由奴隶自己决定的。主人是否发送了一些信号，表明它应该产生一个新的中继日志？
我正在停用旧的 mysql 服务器。当然，还有一些东西定期与它相连，人们已经忘记了。我打开了一般查询日志记录以更好地了解那里仍在进行的事情以追踪罪魁祸首并注意到一些奇怪的事情。
有一个条目如下：
870 Connect <user>@<server> on
它继续进行并以 a 结尾
870 Quit
下一行是
1143 Connect <user>@<server>
为什么线程 ID 会跳跃？只需 grep 出所有“连接”行，就会出现递增线程 ID +1 的爆发，然后是下一个连接 ID 的不同大小间隙。
这是预期的行为吗？
无论如何，如果索引列是索引的第一部分，是否可以用 SQL 来判断。
最接近的东西看起来是 information_schema.columns。但这似乎只告诉我它是 PRI 还是 MUL 键（而不是它是否是该索引的唯一成员，或者如果它是复合键则它的位置）。
我试图找出与数据截断相关的一些警告消息之间的区别。考虑下表：
CREATE TABLE `txttest` (
`mycol` text NOT NULL )
ENGINE=InnoDB DEFAULT CHARSET=utf8;
几乎预期的行为：
mysql > insert into txttest (mycol) values (repeat('a',65535));
Query OK, 1 row affected (0.17 sec)
mysql > insert into txttest (mycol) values (repeat('a',65536));
Query OK, 1 row affected, 1 warning (0.16 sec)
mysql > show warnings;
+---------+------+--------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------+
| Warning | 1265 | Data truncated for column 'mycol' at row 1 |
+---------+------+--------------------------------------------+
1 row in set (0.00 sec)
但是，当我使用多字节字符时，会出现预期的警告状态，但消息不同：
mysql > insert into txttest (mycol) values (repeat('é',65536/2-1));
Query OK, 1 row affected (0.17 sec)
mysql > insert into txttest (mycol) values (repeat('é',65536/2));
Query OK, 1 row affected, 1 warning (0.16 sec)
mysql > show warnings;
+---------+------+----------------------------------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------------------------------+
| Warning | 1366 | Incorrect string value: '\xC3\xA9' for column 'mycol' at row 1 |
+---------+------+----------------------------------------------------------------+
1 row in set (0.00 sec)
谷歌的尝试并不是很有用，因为我主要是针对不同的上下文运行此消息的粘贴。
基本上我想知道的是：这只是Mysql在截断多字节字符序列时使用的措辞/错误代码，还是有更多的东西告诉我应该从这条消息中收集信息？
我最初认为这意味着字节序列被分割得如此之远，导致字符格式错误。试图让它做到这一点的尝试并没有奏效（例如mysql似乎很好地识别字符编码的正确字节边界）。
编辑：
在重新审视之后，它看起来确实是我最初驳回的字符分裂。最初看它时，我大吃一惊。
我有几个问题要问那些更熟悉的人。尽管支持 Barracuda，但我的大多数实例都在运行 Antelope。
我正在寻找一些压缩 innodb 表。我的理解是这仅在梭子鱼格式下可用。
- 我看到 innodb_file_format 是动态的，所以我可以切换而不会反弹。我应该注意这样做是否有任何影响。我只能说这意味着将使用该格式创建新表或随后更改的表。这一切都正确吗？
- 我希望不必经历并转换我所有的表格。羚羊和梭子鱼表在同一个表空间中共存是否符合犹太教规？即使它有效，是否有任何需要注意的问题？
根据我阅读并从测试中收集的内容，答案是：是的。是的。我不确定。
更新
自从这篇文章以来，我一直在各种情况下运行一些动态表和一些压缩表，没有问题。 此外，我当时 忽略了阅读http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html 。
启用给定的 innodb_file_format 后，此更改仅适用于新创建的表，而不适用于现有表。如果您确实创建了一个新表，则包含该表的表空间将使用表功能所需的“最早”或“最简单”文件格式进行标记。例如，如果您启用文件格式 Barracuda，并创建一个未压缩且不使用 ROW_FORMAT=DYNAMIC 的新表，则包含该表的新表空间将标记为使用文件格式 Antelope。
因此，即使您允许 Barracuda，表格也会被创建为 Antelope。除非您将每个表指定为 row_format 动态表或压缩表，否则混合是不可避免的。
没有迹象表明您应该在引入您的第一个梭子鱼表时进行完整的转储和重新加载（例如在升级 mysql 的主要版本时推荐）
我猜答案是否定的，但我想知道是否有办法告诉 innodb 不要将获取的页面存储在缓冲池中？
考虑这样做的原因是检查汇总表。我想尽量减少丢弃有用的缓存数据的影响。
有没有办法在存储过程中确定您正在运行的服务器的主机名？
您可以从客户端运行系统主机名，但不能从 SP 进行系统调用。我没有看到任何全局变量或状态。
我想创建一个存储过程/事件来执行一些维护任务。我的设置是为故障转移场景配置的主/从（意味着从不用于报告，只是在主主故障的情况下可能会升级）。
我想让这个存储过程在两者的事件调度程序中运行。在正常的操作过程中，我希望它做它的事情，让这些操作通过正常的复制链流动。在故障转移的情况下，我希望它只是检测到它不是主人并继续处理以前的奴隶。（在这样的事件中，不必担心就位的事情）。
我正在考虑将初始调用包装在一个看起来像的伪代码块中
如果 I_AM_MASTER 那么
调用 real_work_sp;
万一;
测试 I_AM_MASTER 的最佳方法是什么？我知道我可以从命令行显示主状态，但我不确定如何捕获该状态以用于此测试。我该怎么做，或者有更好的方法吗？
PS 这些操作不仅仅是删除，如果它们碰巧运行两次，我可以让“失败”。