SearchApiException: Unknown server profile_server

Well, is there a search server with the machine name "profile_server" on your site? Otherwise, just move the index to an existing server and it should work.

I don't think the problem could be caused by profile2. But you could check whether it also occurs with other indexes (e.g., one on nodes), if you want to be sure.

Also, the Beta 9 release of Entity API had a few problems. Maybe try to update it to the latest dev version and see if that solves the problem.

Well, then please see what's wrong with the fields processed by that filter. You can do that by adding a debug line to the used server's index() method, outputting $items, and then manually indexing a single profile.

However, this still doesn't solve the problem with the exception, right? For that, I'd still like to know whether you have (or had previously) a server with that machine name.

Also, I've noticed that the body field and a taxonomy field containing multiple values (attached to my profile type) isn't indexed at all. Is this something that should work? Does it work on node entities ATM? Maybe it's the profile entity screwing things up somehow...

Yes, this should also definitely work. And since the eRecruiter distribution indexes profiles with the Search API, this should be pretty well-tested, too. Maybe a recently introduced incompatibility? In any case, if the field is NULL in $items, there's probably something going wrong in search_api_extract_fields().

Upgrading PAST 7.x-1.0-beta10 to 7.x-1.x-dev was needed for me to stop seeing this error everytime I deleted content. Looks like the current code does a better job of cleaning up after itself.

Hmm spoke too soon. Getting errors on content creation now. Looks like one needs to uninstall and reinstall search_api if your setup gets messed up.

With this little information, I can't really know what might cause the problem and, therefore, how to fix it. If you provide more information and maybe some debugging data, maybe we can find and eliminate the underlying bug.

Sorry if this gets long...

My problem was originally that mysql marked a table as "crashed" because of too many duplicate key inserts. Maybe my indexed field wasn't unique enough somehow, maybe search api needs to make better sure of the uniqueness of the search keys it is generating with some kind of hash or something. Maybe there is a unique index constraint on the db table where there shouldn't be one.

Anyway, started getting horrible errors ( PDO exceptions etc..) every time I tried to create or delete a node so I disabled search api while I tried to figure out what to do about the table. I ended up recreating the table structure for that one table in mysql, but search api was still not happy (I think the same errors) and I decided to delete the indexes and start over.

Unfortunately, the error on node insert changed at that point to complaining about the lack of the old index being there.

So I deactivated, then uninstalled the Mysql backend module for search_api hoping the references for the old index got cleared out. Didn't work.

At this point, I read this thread and noted that there may have been some improvement in the code handling index/server swaps between the last beta and june and the current dev code. I upgraded to the latest code, and the error on insert went away. Unfortunately, the errors on delete remained.

So, I completely nuked my search api setup, deactivating and uninstalling all sub modules. This helped :) But of course a lot of work was lost.

My problem was originally that mysql marked a table as "crashed" because of too many duplicate key inserts. Maybe my indexed field wasn't unique enough somehow, maybe search api needs to make better sure of the uniqueness of the search keys it is generating with some kind of hash or something. Maybe there is a unique index constraint on the db table where there shouldn't be one.

If you are using the database backend and you are getting those during indexing, this is actually a flaw in Drupal that I can do little to circumvent. See #1144620: Fix character collation problems and #1144644: Enable specifying the collation when creating a database table.

As for the index deletions: If you deleted them via the normal UI (not via the database), this is definitely a bug and was hopefully already fixed. Otherwise, it would be good to know what exactly is complaining about the missing index (a view, a search page, facets, …?).

Thank you for the detective work on the mysql key problems. Yes, this looks precisely the type of issues I was getting with German umlauts. Your workaround suggestions in #1144620: Fix character collation problems look worth trying. In fact they, look worth documenting in the Readme as a necessity when using a mysql backend.

Follow-up: #1903004: SearchApiException: Search server with machine name Foo specifies illegal service class search_api_db_service