Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Configurations Amazon MSK personnalisées
Vous pouvez utiliser Amazon MSK pour créer une configuration MSK personnalisée dans laquelle vous définissez les propriétés suivantes. Les propriétés que vous ne définissez pas obtiennent explicitement les valeurs qu'elles ont dans Configuration par défaut d'Amazon MSK. Pour de plus amples informations sur les propriétés de configuration, veuillez consulter Configuration d'Apache Kafka
| Name (Nom) | Description |
|---|---|
| allow.everyone.if.no.acl.found | Si vous souhaitez définir cette propriété surfalse, assurez-vous d'abord de définir Apache Kafka ACLs pour votre cluster. Si vous attribuez à cette propriété false la valeur sans définir Apache Kafka au préalable ACLs, vous perdez l'accès au cluster. Dans ce cas, vous pouvez à nouveau mettre à jour la configuration et définir cette propriété sur true pour accéder de nouveau au cluster. |
| auto.create.topics.enable | Active la création automatique de rubriques sur le serveur. |
| compression.type | Type de compression final pour une rubrique donnée. Vous pouvez définir cette propriété sur les codecs de compression standard (gzip, snappy, lz4 et zstd). Il accepte en outre uncompressed. Cette valeur équivaut à l'absence de compression. Si vous définissez la valeur sur producer, cela implique de retenir le codec de compression d'origine défini par le producteur. |
|
connections.max.idle.ms |
Délai d'expiration des connexions inactives en millisecondes. Les threads du processeur de socket de serveur ferment les connexions inactives pendant une durée supérieure à la valeur que vous avez définie pour cette propriété. |
| default.replication.factor | Facteur de réplication par défaut pour les rubriques créées automatiquement. |
| delete.topic.enable | Active l'opération de suppression de rubrique. Si vous désactivez cette configuration, vous ne pouvez pas supprimer une rubrique via l'outil d'administration. |
| group.initial.rebalance.delay.ms | Temps pendant lequel le coordinateur du groupe attend que davantage de consommateurs de données rejoignent un nouveau groupe avant d'effectuer le premier rééquilibrage. Un délai plus long signifie potentiellement moins de rééquilibrages, mais augmente le temps jusqu'au début du traitement. |
| group.max.session.timeout.ms | Délai maximal de session pour les consommateurs enregistrés. Les délais d'expiration plus longs donnent aux consommateurs plus de temps pour traiter les messages entre les battements de cœur, au prix d'un délai plus long pour détecter les défaillances. |
| group.min.session.timeout.ms | Délai d'expiration minimum de session pour les consommateurs enregistrés. Des délais d'expiration plus courts entraînent une détection plus rapide des défaillances, au prix des battements de cœur plus fréquents des consommateurs. Cela peut surcharger les ressources des agents. |
| leader.imbalance.per.broker.pourcentage | Ratio de déséquilibre de leader autorisé par courtier. Le contrôleur déclenche un équilibrage de leader s'il dépasse cette valeur par agent. Cette valeur est spécifiée en pourcentage. |
| log.cleaner.delete.retention.ms | Durée pendant laquelle vous souhaitez qu'Apache Kafka conserve les enregistrements supprimés. La valeur minimale est 0. |
| log.cleaner.min.cleanable.ratio |
Cette propriété de configuration peut avoir des valeurs comprises entre 0 et 1. Cette valeur détermine la fréquence à laquelle le compacteur de journal tente de nettoyer le journal (si le compactage du journal est activé). Par défaut, Apache Kafka évite de nettoyer un journal si plus de 50 % du journal a été compacté. Ce ratio limite l'espace maximal que le journal gaspille avec des doublons (à 50 %, cela signifie que le journal peut contenir tout au plus 50 % de doublons). Un ratio plus élevé signifie moins de nettoyages, plus efficaces, mais aussi plus d'espace perdu dans le journal. |
| log.cleanup.policy | Stratégie de nettoyage par défaut pour les segments au-delà de la fenêtre de rétention. Liste de stratégies valides séparées par des virgules. Les stratégies valides sont delete et compact. Pour les clusters compatibles avec le stockage hiérarchisé, la politique valide est delete uniquement. |
| log.flush.interval.messages | Nombre de messages accumulés sur une partition de journal avant que les messages ne soient vidés sur le disque. |
| log.flush.interval.ms | Durée maximale en millisecondes pendant laquelle un message dans une rubrique est conservé en mémoire avant d'être vidé sur le disque. Si vous ne définissez pas cette valeur, la valeur de log.flush.scheduler.interval.ms est utilisée. La valeur minimale est 0. |
| log.message.timestamp.difference.max.ms | Cette configuration est obsolète dans Kafka 3.6.0. Deux configurations, log.message.timestamp.before.max.ms etlog.message.timestamp.after.max.ms, ont été ajoutées. Différence de temps maximale autorisée entre l'horodatage lorsqu'un agent reçoit un message et l'horodatage spécifié dans le message. Si log.message.timestamp.type=CreateTime, un message est rejeté si la différence d'horodatage dépasse ce seuil. Cette configuration est ignorée si LogAppendTime log.message.timestamp.type=. |
| log.message.timestamp.type | Spécifie si l'horodatage du message est l'heure de création du message ou l'heure d'ajout du journal. Les valeurs autorisées sont CreateTime et LogAppendTime. |
| log.retention.bytes | Taille maximale du journal avant de le supprimer. |
| log.retention.hours | Nombre d'heures pour conserver un fichier journal avant de le supprimer, tertiaire à la propriété log.retention.ms. |
| log.retention.minutes | Nombre de minutes de conservation d'un fichier journal avant de le supprimer, secondaire à la propriété log.retention.ms. Si vous ne définissez pas cette valeur, la valeur de log.retention.hours est utilisée. |
| log.retention.ms | Nombre de millisecondes pour conserver un fichier journal avant de le supprimer (en millisecondes), si ce n'est pas défini, la valeur dans log.retention.minutes est utilisée. |
| log.roll.ms | Durée maximale avant le déploiement d'un nouveau segment de journal (en millisecondes). Si vous ne définissez pas cette valeur, la valeur de log.roll.hours est utilisée. La valeur minimale possible pour cette propriété est 1. |
| log.segment.bytes | Taille maximale d'un seul fichier journal. |
| max.incremental.fetch.session.cache.slots | Nombre maximal de sessions d'extraction incrémentielle qui sont maintenues. |
| message.max.octets |
La plus grande taille de lot d'enregistrement autorisée par Kafka. Si vous augmentez la valeur et qu'il y a des consommateurs plus anciens que 0.10.2, vous devez aussi augmenter la taille d'extraction des consommateurs afin qu'ils puissent récupérer des lots d'enregistrements aussi volumineux. La dernière version de format de message regroupe toujours les massages en lots pour plus d'efficacité. Les versions de format de message précédentes ne regroupent pas les enregistrements non compressés en lots et dans ce cas, cette limite ne s'applique qu'à un seul enregistrement. Vous pouvez définir cette valeur par rubrique avec le niveau de rubrique max.message.bytes config. |
| min.insync.replicas |
Lorsqu'un producteur définit acks sur Vous pouvez utiliser des valeurs dans min.insync.replicas et acks pour appliquer de meilleures garanties de durabilité. Par exemple, vous pouvez créer une rubrique avec un facteur de réplication de 3, définir min.insync.replicas sur 2 et produire avec des acks de |
| num.io.threads | Nombre de threads utilisés par le serveur pour le traitement des demandes, qui peuvent inclure des E/S de disque. |
| num.network.threads | Nombre de threads que le serveur utilise pour recevoir des demandes du réseau et lui envoyer des réponses. |
| num.partitions | Nombre par défaut de partitions de journal par rubrique. |
| num.recovery.threads.per.data.dir | Nombre de threads par répertoire de données à utiliser pour récupérer des journaux au démarrage et pour leur vidage lors de l'arrêt. |
| num.replica.fetchers | Nombre de threads de récupération utilisés pour répliquer les messages d'un broker source. Si vous augmentez cette valeur, vous pouvez augmenter le degré de parallélisme d'E/S dans l'agent suiveur. |
| offsets.retention.minutes | Lorsqu'un groupe de consommateurs perd tous ses consommateurs (c'est-à-dire qu'il devient vide), ses compensations sont conservées pour cette période de rétention avant d'être jetées. Pour les consommateurs autonomes (c'est-à-dire ceux qui utilisent l'affectation manuelle), les décalages expirent après l'heure de la dernière validation plus cette période de conservation. |
| offsets.topic.replication.factor | Facteur de réplication de la rubrique des décalages. Définissez cette valeur à un niveau supérieur pour garantir la disponibilité. La création de rubrique interne échoue jusqu'à ce que la taille du cluster réponde à cette exigence de facteur de réplication. |
| réplica.fetch.max.bytes | Nombre d'octets de messages à essayer de récupérer pour chaque partition. Ce n'est pas un maximum absolu. Si le premier lot d'enregistrements de la première partition non vide de l'extraction est supérieur à cette valeur, le lot d'enregistrements est renvoyé pour assurer la progression. Les message.max.bytes (broker config) ou max.message.bytes (topic config) définissent la taille maximale du lot d'enregistrements que l'agent accepte. |
| replica.fetch.response.max.bytes | Nombre maximal d'octets attendu pour l'ensemble de la réponse de récupération. Les enregistrements sont récupérés par lots, et si le premier lot d'enregistrements de la première partition non vide de l'extraction est supérieur à cette valeur, le lot d'enregistrements sera toujours renvoyé pour assurer la progression. Ce n'est pas un maximum absolu. Les propriétés message.max.bytes (broker config) ou max.message.bytes (topic config) spécifient la taille maximale du lot d'enregistrements que le broker accepte. |
| replica.lag.time.max.ms | Si un suiveur n'a envoyé aucune demande d'extraction ou n'a pas consommé le décalage de fin existant avec le journal du leader pendant au moins ce nombre de millisecondes, le leader supprime le suiveur de l'ISR. MinValue: 10000 MaxValue = 30000 |
| replica.selector.class | Le nom de classe complet qui implémente ReplicaSelector. L'agent utilise cette valeur pour trouver le réplica en lecture préféré. Si vous utilisez Apache Kafka, version 2.4.1 ou supérieure, et que vous souhaitez permettre aux consommateurs de récupérer le réplica le plus proche, définissez cette propriété sur org.apache.kafka.common.replica.RackAwareReplicaSelector. Pour de plus amples informations, veuillez consulter Apache Kafka version 2.4.1 (utilisez plutôt 2.4.1.1). |
| replica.socket.receive.buffer.bytes | Tampon de réception du socket pour les demandes réseau. |
| socket.receive.buffer.bytes | Tampon SO_RCVBUF des sockets de serveur de socket. La valeur minimale que vous pouvez définir pour cette propriété est -1. Si la valeur est -1, Amazon MSK utilise le système d'exploitation par défaut. |
| socket.request.max.octets | Nombre maximal d'octets dans une requête socket. |
| socket.send.buffer.bytes | Tampon SO_SNDBUF des sockets de serveur de socket. La valeur minimale que vous pouvez définir pour cette propriété est -1. Si la valeur est -1, Amazon MSK utilise le système d'exploitation par défaut. |
| transaction.max.timeout.ms | Délai maximal pour les transactions. Si le temps de transaction demandé à un client dépasse cette valeur, le courtier renvoie une erreur InitProducerIdRequest. Cela évite au client un délai d'expiration trop important et cela peut empêcher les consommateurs de lire des rubriques incluses dans la transaction. |
| transaction.state.log.min.isr | Configuration min.insync.replicas remplacée pour la rubrique de la transaction. |
| transaction.state.log.replication.factor | Facteur de réplication de la rubrique de la transaction. Configurez cette propriété sur une valeur plus élevée pour augmenter la disponibilité. La création de rubrique interne échoue jusqu'à ce que la taille du cluster réponde à cette exigence de facteur de réplication. |
| transactional.id.expiration.ms | Durée en millisecondes pendant laquelle le coordinateur de transactions attend de recevoir les mises à jour du statut de la transaction en cours avant que l'ID transactionnel du coordinateur n'expire. Ce paramètre influence également l'expiration de l'identifiant du producteur, car il entraîne l' IDsexpiration du producteur lorsque ce délai s'écoule après la dernière écriture avec l'identifiant de producteur donné. Le producteur IDs peut expirer plus tôt si la dernière écriture provenant de l'identifiant du producteur est supprimée en raison des paramètres de conservation du sujet. La valeur minimale pour cette propriété est 1 milliseconde. |
| unclean.leader.election.enable | Indique si les réplicas ne figurant pas dans l'ensemble ISR doivent servir de leader en dernier recours, même si cela peut entraîner une perte de données. |
| zookeeper.connection.timeout.ms | ZooKeeper clusters de modes. Durée maximale pendant laquelle le client attend avant d'établir une connexion. ZooKeeper Si vous ne définissez pas cette valeur, la valeur de zookeeper.session.timeout.ms est utilisée. MinValue = 6000 MaxValue (inclus) = 18000 |
| zookeeper.session.timeout.ms |
ZooKeeper clusters de modes. Le délai d'expiration de ZooKeeper la session Apache en millisecondes. MinValue = 6000 MaxValue (inclus) = 18000 |
Pour savoir comment créer une configuration MSK personnalisée, dresser une liste de toutes les configurations ou les décrire, veuillez consulter Opérations de configuration du broker. Pour créer un cluster MSK à l'aide d'une configuration MSK personnalisée ou pour mettre à jour un cluster avec une nouvelle configuration personnalisée, consultez Caractéristiques et concepts clés d'Amazon MSK.
Lorsque vous mettez à jour votre cluster MSK existant avec une configuration MSK personnalisée, Amazon MSK redémarre la propagation lorsque nécessaire et utilise les bonnes pratiques pour limiter les temps d'arrêt du client. Par exemple, après qu'Amazon MSK a redémarré chaque agent, il essaie de laisser l'agent rattraper les données que l'agent a pu manquer lors de la mise à jour de la configuration avant de passer à l'agent suivant.
Configuration dynamique d'Amazon MSK
Outre les propriétés de configuration fournies par Amazon MSK, vous pouvez définir dynamiquement les propriétés de configuration au niveau du cluster et de l'agent qui ne nécessitent pas de redémarrage de l'agent. Vous pouvez définir certaines propriétés de configuration de manière dynamique. Il s'agit des propriétés qui ne sont pas marquées en lecture seule dans la table sous Configurations de l'agent
Note
Vous pouvez définir la propriété advertised.listeners, mais pas la propriété listeners.
Configuration Amazon MSK au niveau du sujet
Vous pouvez utiliser les commandes Apache Kafka pour définir ou modifier les propriétés de configuration au niveau des rubriques nouvelles et existantes. Pour de plus amples informations sur les propriétés de configuration au niveau de la rubrique et pour obtenir des exemples de définition, consultez Configurations au niveau de la rubrique
