我有一个 MyISAM 格式的大约 300M 行的表，我想转换为 Innodb
我最初的目标是通过将表架构更改为具有更简单的索引来减少使用。我转储了所有表，删除了它，用更少的索引重新创建它，现在正在重新导入。但是，我忘记指定它应该是innodb而不是myisam。
我可以做标准的 ALTER TABLE ... ENGINE=INNODB 吗？这么大的桌子有什么特别我应该注意的吗？
数据导入操作大约需要 12 个小时——我不想再这样做了。因此，为什么我只想转换它。
我想将 Nagios 设置为通过电子邮件发出警告（例如，负载或磁盘使用量略高），但对于关键项目，要通过寻呼机发出警报。
现在，我们同时通过电子邮件和寻呼机通知所有警告。我的通用接触定义如下：
define contact{
name generic-contact
service_notification_options w,u,c,r,f,s
host_notification_options d,u,r,f,s
service_notification_commands notify-service-by-email,notify-service-by-pager
host_notification_commands notify-host-by-email,notify-host-by-pager
register 0
service_notification_period 24x7
host_notification_period 24x7
}
我如何才能使警告和严重的电子邮件通知都发生，但仅对严重的进行分页？
我有一个通过 cookie 进行负载平衡的系统，但我想使用 URL 参数作为替代。（具体来说，我有一个不支持 cookie 的前端应用程序）。我的设置有点复杂 - 我有一个多人游戏系统，我使用带有这个 cookie 的棒桌来确保玩同一个游戏的不同人去同一个服务器。这很好用，除了 URL 参数似乎没有做任何事情。这都是haproxy 1.5dev17
我的相关后端是：
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
option http-server-close
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
backend simulate
option httpchk OPTIONS /simulate/api/status
stick-table type string len 40 size 5M expire 30m
stick store-response set-cookie(SIMULATE_STICKY_SESSION) table simulate
stick on cookie(SIMULATE_STICKY_SESSION) table simulate
stick on url_param(SIMULATE_STICKY_SESSION) table simulate
server app1 10.0.2.11:8080 cookie app1 check inter 10000
server app2 10.0.3.11:8080 cookie …我有一个 1 TB 的 MySQL 数据库，我想转储并重新加载它。大部分数据都在一张表中。很多数据被删除了，所以我很确定如果我用mysql转储它，重建数据库，然后重新加载它总大小会更小。
我正在使用此命令转储数据：
mysqldump -uroot -pXXX mydb | gzip -c > data.sql.gz
我收到这个错误
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `MY_TABLE` at row: 596089342
我尝试了许多变体，包括增加数据包大小、进行单一转换和通过 TCP/IP 而不是本地套接字。
mysqldump -uroot -pXXX -h 127.0.0.1 --max-allowed-packet=1024M --single-transaction mydb | gzip -c > data.sql.gz
最后，我什至运行命令到 /dev/null 以确保它不是 gzip。所有排列都会产生相同的错误。
mysqldump -uroot -pXXX -h 127.0.0.1 mydb > /dev/null
这是 my.cnf 中的一些设置
max_allowed_packet = 1G
interactive_timeout = 600
wait_timeout = 600
net_read_timeout=600
net_write_timeout=600
connect_timeout=600
另一件奇怪的事情是转储总是停在同一个地方。大约 6GB 的 …
我在会话累积时遇到问题。我在 Windows 服务器上运行 Tomcat 6.0.18 的实例。我有 3 个应用程序。
我一直有内存问题（接近堆大小或 OOM）。当我查看 Tomcat 管理器时，我在 3 个应用程序中的每一个中看到 500-1000 个会话。当我在 Tomcat 管理器中查看会话时，我可以看到一些会话处于空闲时间多个小时，但它们并没有过期。
其中一个 webapps 有 10 分钟的超时时间，但在代码中设置为 60 分钟（对于某些用户）。其他应用程序有 15 分钟和 30 分钟的超时时间。我还有一个问题，即 webapp 1 使用错误的会话 cookie 重复命中（这与我的 mod_jk 负载平衡有关），这会增加会话计数。（使用单个请求创建的许多会话都有 60 分钟的超时时间）。但令我感到困惑的是，webapp 2 和 3 的会话也越来越多，而且它们甚至在超时后仍然存在。
我的理论是会话清理仅在服务器负载不重时才发生，并且（在这种情况下）如此多的会话累积，服务器的可用 CPU 很少，并且清理永远不会运行。但是我找不到任何参考资料来支持这个理论。
有谁知道会话过期算法的细节？它并不完全在超时分钟内运行——它什么时候运行？
我需要更改具有 164M 行的 MySQL innodb 表中的列长度。这是我要运行的脚本： ALTER TABLE SESSION_DECISION CHANGE COLUMN NAME NAME VARCHAR(255);
当我尝试运行更改查询时，数据库搅动了一个小时并且没有完成任务。访问系统的用户（需要写入表的用户）被锁定。这是一个实时系统，因此我最终控制了请求以允许用户访问该站点。
（这是在半夜——使用量很少，但我感到紧张）。
我使用的是 MySQL 5.0.77。
关于如何以最短的停机时间更换色谱柱，您有什么建议吗？