[MDEV-15552] SphinxSE lets MariaDB Server restarting Created: 2018-03-12 Updated: 2020-05-06 Resolved: 2018-07-13 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - SphinxSE |
| Affects Version/s: | 10.1.31 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Jens Bosse | Assignee: | Unassigned |
| Resolution: | Incomplete | Votes: | 0 |
| Labels: | need_feedback | ||
| Environment: |
Debian 8 |
||
| Description |
|
No idea if this is really a bug, but we do not know any further here. We are running MariaDB server (following S1) with databases using a table of type SphinxSE engine. The Sphinx daemon is running on another server (following S2). On S2 also runs MariaDB as slave, which should keep the data of the S1 updated by replication. The daemon gets the data for different indices from the S2. We switched from MySQL to MariaDB because SphinxSe engine is already integrated. Now the problem: We have no idea what the problem described could be, even google searches are not very helpful. SphinxSE-Table: Sample query: Is there any more data needed? Please assist. Thanks |
| Comments |
| Comment by Jens Bosse [ 2018-06-12 ] |
|
No support at all? |
| Comment by Elena Stepanova [ 2018-06-12 ] |
|
There isn't much to work with here. When you are saying "When the table exist the engine type SphinxSE at S1 regularly restarts", what do you mean by that? What restarts? MariaDB server on S1? The machine itself? The connection? Assuming it's the server, how does it look exactly, that it restarts but no error messages? Does it shut down on its own? Does it just disappear? Does it produce a coredump (assuming you have them enabled)? Unless it's clearly a bug on the database server side, probably your better bet for support is contacting Sphinx developers and community. |
| Comment by Jens Bosse [ 2020-05-06 ] |
|
I apologize for the very late reply. But maybe that will help someone with the same problem. But a while ago, after a long investigation into the problem, we found the cause. We have several indexes. These were selected with an ALTER TABLE ... connection = "... /index". I cannot say exactly what is happening there in the background, but apparently the previous connections were not used again and not closed. So the connections probably filled the RAM more and more. After we created a table for each index the problem disappeared. |