233
OceanBase由於合並操作導致事務被殺死的情況。
OceanBase是一台內存數據庫，兼容MySQL協議以及SQL協議，擁有跟內存數據庫一樣的屬性：所有的數據都需要先寫入到內存裏麵，但是並不會立刻落盤寫入到存儲裏麵，需要等一次合並操作，將內存裏麵所有的改動落盤到存儲裏麵。所以發生這種合並操作的時候，伴隨著資源的使用，也會出現問題。我們來看其中一種由於合並操作導致數據庫殺死事務的情況如何排查。
機器配置：
2c8g
應用端報錯信息：
係統未知錯誤，請聯係管理員： transaction error，need to rollback。
第一次遇到這種問題也是比較懵的，因為平常測試庫的壓力不大，而且合並時間都在淩晨，一般不會出現這種問題。所以排查也是衝頭到尾一步一步梳理的。
排錯過程：
首先確認一下所有的observe是否都正常。
可以直接使用observe機器所在的IP直接連接，或者是查看端口是否通等等的。確認無誤。
然後查看相關監控信息如下：
監控信息裏麵能反應出一些事情來，確實那個時間段相對的係統負載要比平時高。
然後，看一下是否由於壓力的問題，導致了係統發生了合並操作。
OceanBase (root@oceanbase)> show tables like '%rootservice%';
+-------------------------------------+
| Tables_in_oceanbase (%rootservice%) |
+-------------------------------------+
| __all_rootservice_event_history |
| __all_rootservice_job |
+-------------------------------------+
2 rows in set (0.02 sec)
select * from __all_rootservice_event_history where gmt_create between '2017-09-25 16:00:00' and '2017-09-25 17:00:00' order by gmt_create;
發現在故障時間點確實是存在合並操作的。通過之前的操作可以看到75是這次合並操作的序號
select count(*)
from __all_rootservice_event_history
where gmt_create between '2017-09-25 16:00:00' and '2017-09-25 17:00:00' and
value1 = 75
order by gmt_create;
show parameters like '%turn%';這是一次非計劃的合並，說明性能測試寫操作太勐，租戶的memstore增長太快，達到一定閾值後就自動觸發了合並操作。
最後更新：2017-10-04 16:03:05