Nemohu najít citaci v dokumentaci, ale moje zkušenost naznačuje, že síťová infrastruktura EC2 obecně (která by zahrnovala RDS a pravděpodobně jakoukoli jinou službu AWS, která běží na virtuálních počítačích, které jsou poskytovány pro každého zákazníka, pokud ne všechny AWS, a rozhodně se nezdá být omezeno striktně na "EC2 instance"), implementuje stavovou kontrolu paketů a "zapomene", že TCP spojení je platné po několika minutách absolutní nečinnosti... způsobí chování, které popisujete.
Stroje na obou koncích připojení mohou být přesvědčeny, že připojení stále existuje, ale síť nedovolí, aby mezi nimi procházel provoz, protože relace TCP v prostředí SPI nejsou objeveny, jsou vytvářeny a mohou pouze být vytvořen, když síť uvidí připojení na samém začátku (SYN, SYN/ACK, ACK ). Původně jsem se s tímto problémem setkal u serverů MySQL v EC2 (nikoli RDS), ale byl bych velmi překvapen, kdyby základní příčina nebyla stejná.
Existují dva možné přístupy, jak to obejít.
Pokud je váš stroj PHP Linux, nakonfigurujte jádro tak, aby udrželo připojení na vrstvě 4. Tato změna pro vás nebude viditelná v tom smyslu, že tato udržovací zařízení nezmění hodnotu v Time ve sloupci SHOW PROCESSLIST pro připojení v Sleep protože to neresetuje dobu, po kterou bylo připojení nečinné na vrstvě 7... ale mělo by se vyhnout časovým limitům z infrastruktury AWS, pokud knihovny spravující připojení MySQL správně nastavují možnosti soketu, aby toho využily.
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive .html vysvětluje, jak to nastavit živě a jak zajistit, aby to bylo trvalé po restartování.
Pokud se tak nestane, druhou možností je přinutit MySQL k uzavření připojení dříve, než vyprší časový limit sítě takže stroj PHP okamžitě rozpozná, že se pokouší mluvit na uzavřeném soketu. Může znít neintuitivně zkrátit časový limit, spíše než jej prodloužit, ale zkrácení časového limitu by mělo způsobit, že váš pingový test selže velmi rychle, pokud byla relace nečinná příliš dlouho, což také (v podstatě) „vyřeší“ problém, za předpokladu zdravého rozumu. v klientské knihovně PHP. Jakmile je vaše aplikace zaneprázdněnější, připojení budou pravděpodobně jen zřídka nečinná tak dlouho, aby dosáhla časového limitu.
MySQL Server má dvě různá nastavení časového limitu nečinnosti: wait_timeout
(pro neinteraktivní relace, tj. připojení z kódu, jako je PHP) a interactive_timeout
(z dotazovacích prohlížečů a klienta příkazového řádku), ale server pozná pouze rozdíl, protože klientská knihovna musí serveru oznámit, jaký typ připojení vytváří. Za předpokladu, že vaše klientská knihovna používá správné nastavení, pak wait_timeout je ten, kterého hledáte. Nastavení na hodnotu pod 900 by mělo problém vyřešit, pokud to nepomůže změna nastavení TCP keepalive v linuxovém jádře. Všimněte si však, že po provedení změny budou ovlivněna pouze budoucí připojení -- připojení již navázaná při provedení změny budou stále spuštěna s aktuální hodnotou, která je výchozí 8 hodin (28 800 sekund). Ty jsou konfigurovatelné ve skupině parametrů RDS pro vaši instanci.
V dokumentech AWS jsou náznaky podobného chování , spolu s nastavením registru Windows, které je třeba upravit pro změnu udržování TCP, pokud používáte server PHP na Windows, místo na Linuxu, jak jsem předpokládal výše... i když je článek konkrétně o Redshiftu a externích připojeních EC2 se zdá, že stále potvrzuje základní problém, jak je diskutováno výše.