This is a great chance to flesh-out the basics of how CAs work. I will assume that we're talking about root CAs here, since renewing a subordinate CA is not really a big deal.
How often do CA's renew the keys, and under what circumstances (number of certificates issued, time, etc.)?
I will re-phrase this question:
What factors increase an attacker's likelihood of cracking the CA's private key?
Assuming we're not talking about hacks, backdoors, insider threat, etc, and only talking about cracking based on public information, then the answer is: the choice of algorithm, key size, and amount of time.
The calculation goes something like this: say we choose RSA-4096, then we'd look up the runtime of the best known attacks against RSA, look up costs for renting that amount of computing power on Amazon, do some Moore's Law calculations and take a guess how long it would take an attacker to break it. It turns out for RSA and ECC that the best known attacks only need the public key; a signature leaks zero information about the private key, so seeing lots of signatures does not help.
Note that this will not be true for some of the post-quantum signature algorithms. In particular with hash-based signatures [article1], [article2], the private keys are essentially huge collections of single-use keys where each signature reveals a private key. Once the worlf switches to post-quantum crypto, your question will become much more relevant.
In the case that a CA needs to renew its key pair, what happens with the previous certificates that are still valid? are these signed again under the new key?
This is indeed a fundamental problem with the way CAs are designed. I have seen it be handled in two different ways:
The CA simply won't issue certs that outlive itself. Say you have a CA that issues 1-year certs. When the CA itself has less than a year on it they will stand up a new issuing CA. The old CA is still around for revocation checks and stuff, but no longer issues new certificates.
Cross-certify the old CA with the new one so that when validating a cert issued by the old CA, it will chain to the current CA. This is a bit hacky because there is technically an expired CA in the chain. Most TLS engines do not support this kind of thing, so I have only seen it in closed environments like corporate email or ID badge systems where you have more control over the clients.
Because of the disruption of rolling over a root CA, you want it to be valid for a long time. A quick look through my browser's root certs shows 15 year certs, 20 year certs, and even some 30 year certs.
